 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PicoMite V6.01.00D release candidates
  Page 3 of 3 |
|||||
| Author | Message | ||||
| EDNEDN Senior Member  Joined: 18/02/2023 Location: United StatesPosts: 278 |
You are very welcome. It was fun to write! That message is probably not valuable anymore and can be ignored. I'll double check that it can be removed and get rid of it for the next release. (And eliminate the confusion it caused.) That message is only complaining that the screen's (X,Y) dimensions are not big enough to support the debugger taking over the upper right corner of the screen. The 'D' version of PicoMite_v6.01.00RC??D firmware has the screen size defaulting to (145,45) instead of (80,24). Obviously, if MMBasic is going to support retro-hardware the (80,24) size used to make a lot of sense. That is what was mostly available back in the day. But with today's high resolution screens being used as an ASCII terminal by the user that limitation doesn't have much value anymore. Perhaps somebody can provide a reason why it still makes sense to have the (80,24) screen size be the default, and if so, the screen size could be adjusted higher (quietly!!!!) if the person invokes the debugger. If there are reasons to keep the default at (80,24) please explain the thinking! . Edited 2025-11-21 00:11 by EDNEDN |
||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 8358 |
On a real VT100 the font is 8x9 pixels, giving a display of 53 lines of 80 characters on a 640x480 pixel screen. It may not be possible to generate this using the timing on the Picomite. The default of 80x24 was almost certainly chosen as it will display well on a TFT LCD display as well as a VGA monitor. Making the display width wider takes you out of the native width for most LCD displays so the display might be poor. Remember that you can't enter OPTION DISPLAY unless you can read the screen. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 278 |
I was thinking the 80x24 size was chosen because that is what the old 'Glass CRT' screens were. I think that is what the old VT-52's were??? And of course that carried over into what the LCD panels were developed to handle. It is easy enough to just quietly set the screen size larger and not issue a caution message. Probably that is what makes sense. And RC18 just showed up... So that will provide an opportunity to resolve this. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8358 |
Strictly speaking the line length was 79 characters followed by a CR character. However, by using them carefully you could display 80. :) We had no VGA monitor for the Picomite at first. Only LCD. 640x480 became "the high resolution VGA standard" by virtue of the IBM PC, so I suppose it was a good one to copy. After that you get the characters per line and number of lines decided by what timings you can accommodate. The VT100 used 53 lines of 9 pixel high character cells to get 477 rows of pixels, losing the other 3 rows. The characters were 7 pixels high, plus two rows either blank or for descenders, which touched the row below. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 278 |
PicoMite V6.01.00RC18D Built using PicoMite V6.01.00RC18 with the code updated to silently deal with improper screen size options. PicoMite_v6.01.00RC18D---Documentation.zip PicoMiteV6.01.00RC18D---Firmware.zip . Edited 2025-11-21 04:01 by EDNEDN |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 278 |
PicoMite V6.01.00RC19D now available. Built using PicoMite V6.01.00RC19 with the new Regular Expression engine. PicoMite_v6.01.00RC19D---Documentation.zip PicoMite_v6.01.00RC19D---Firmware.zip . Edited 2025-11-22 04:06 by EDNEDN |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 278 |
PicoMite V6.01.00RC20D now available. There are currently no known issues with the debugger. Built using PicoMite V6.01.00RC20 with the new mid$(), lmid(), instr() and linstr() functions. And of course, the new array dimensioning capabilities. PicoMite_v6.01.00RC20D---Documentation.zip PicoMite_v6.01.00RC20D---Firmware.zip . |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10681 |
EDNEDN, I've tightened the size of the images back to the minimum. I don't know how much extra code you are adding but you need to make sure the image isn't too big for the size allowed in Configuration.h set by FLASH_TARGET_OFFSET. I've created a script to tell me the minimum to set that to rounded up to 16K which is the minimum flash erase size. You might want to just check your images. If it is undersized most of MMbasic will still run but the user will see unexplained bugs. import sys def parse_hex(filename): highest = 0 ext_addr = 0 with open(filename, 'r') as f: for line in f: if not line.startswith(':'): continue length = int(line[1:3], 16) addr = int(line[3:7], 16) rectype = int(line[7:9], 16) if rectype == 4: # Extended Linear Address ext_addr = int(line[9:13], 16) elif rectype == 0: # Data record full_addr = (ext_addr << 16) + addr end_addr = full_addr + length if end_addr > highest: highest = end_addr return highest def round_up(value, boundary): return (value + boundary - 1) // boundary * boundary if __name__ == "__main__": if len(sys.argv) < 2: print("Usage: python GetHighestHexAddress.py firmware.hex") sys.exit(1) filename = sys.argv[1] highest = parse_hex(filename) # Round up to 16-byte boundary safe16 = round_up(highest, 16) # Round up to 16KB boundary safe16k = round_up(highest, 0x4000) # Compute block index relative to flash base flash_base = 0x10000000 blocks = (safe16k - flash_base) // 1024 print(f"Highest written address: 0x{highest:X}") print(f"Rounded up to 16-byte boundary: 0x{safe16:X}") print(f"Rounded up to 16KB boundary: 0x{safe16k:X}") print(f"Equivalent number of 1KB blocks from flash base: {blocks}") My current build file runs this automatically but the check is manual set "fixed_string=V6.01.00RC20" set "extension=.uf2" set "directory=../" ren buildRP2040L build cd build cmake -G "NMake Makefiles" -DCOMPILE=PICO .. nmake set "filename=PicoMiteRP2040" if exist "%filename%%fixed_string%%extension%" del "%filename%%fixed_string%%extension%" copy "PicoMite.uf2" "%directory%%filename%%fixed_string%%extension%" findstr /B ".heap" PicoMite.elf.map :: python ../GetHighestHexAddress.py PicoMite.hex :: cmake -G "NMake Makefiles" -DCOMPILE=PICOUSB .. nmake set "filename=PicoMiteRP2040USB" if exist "%filename%%fixed_string%%extension%" del "%filename%%fixed_string%%extension%" copy "PicoMite.uf2" "%directory%%filename%%fixed_string%%extension%" findstr /B ".heap" PicoMite.elf.map :: python ../GetHighestHexAddress.py PicoMite.hex :: cmake -G "NMake Makefiles" -DCOMPILE=VGA .. nmake set "filename=PicoMiteRP2040VGA" if exist "%filename%%fixed_string%%extension%" del "%filename%%fixed_string%%extension%" copy "PicoMite.uf2" "%directory%%filename%%fixed_string%%extension%" findstr /B ".heap" PicoMite.elf.map :: python ../GetHighestHexAddress.py PicoMite.hex :: cmake -G "NMake Makefiles" -DCOMPILE=VGAUSB .. nmake set "filename=PicoMiteRP2040VGAUSB" if exist "%filename%%fixed_string%%extension%" del "%filename%%fixed_string%%extension%" copy "PicoMite.uf2" "%directory%%filename%%fixed_string%%extension%" findstr /B ".heap" PicoMite.elf.map :: python ../GetHighestHexAddress.py PicoMite.hex :: cmake -G "NMake Makefiles" -DCOMPILE=WEB .. nmake set "filename=WebMiteRP2040" if exist "%filename%%fixed_string%%extension%" del "%filename%%fixed_string%%extension%" copy "PicoMite.uf2" "%directory%%filename%%fixed_string%%extension%" findstr /B ".heap" PicoMite.elf.map :: python ../GetHighestHexAddress.py PicoMite.hex :: cd .. timeout /t 20 /nobreak ren build buildRP2040L ren buildRP2350L build cd build :: cmake -G "NMake Makefiles" -DCOMPILE=WEBRP2350 .. nmake set "filename=WebMiteRP2350" if exist "%filename%%fixed_string%%extension%" del "%filename%%fixed_string%%extension%" copy "PicoMite.uf2" "%directory%%filename%%fixed_string%%extension%" findstr /B ".heap" PicoMite.elf.map :: python ../GetHighestHexAddress.py PicoMite.hex :: cmake -G "NMake Makefiles" -DCOMPILE=VGARP2350 .. nmake set "filename=PicoMiteRP2350VGA" if exist "%filename%%fixed_string%%extension%" del "%filename%%fixed_string%%extension%" copy "PicoMite.uf2" "%directory%%filename%%fixed_string%%extension%" findstr /B ".heap" PicoMite.elf.map :: python ../GetHighestHexAddress.py PicoMite.hex :: cmake -G "NMake Makefiles" -DCOMPILE=VGAUSBRP2350 .. nmake set "filename=PicoMiteRP2350VGAUSB" if exist "%filename%%fixed_string%%extension%" del "%filename%%fixed_string%%extension%" copy "PicoMite.uf2" "%directory%%filename%%fixed_string%%extension%" findstr /B ".heap" PicoMite.elf.map :: python ../GetHighestHexAddress.py PicoMite.hex :: cmake -G "NMake Makefiles" -DCOMPILE=PICORP2350 .. nmake set "filename=PicoMiteRP2350" if exist "%filename%%fixed_string%%extension%" del "%filename%%fixed_string%%extension%" copy "PicoMite.uf2" "%directory%%filename%%fixed_string%%extension%" findstr /B ".heap" PicoMite.elf.map :: python ../GetHighestHexAddress.py PicoMite.hex :: cmake -G "NMake Makefiles" -DCOMPILE=PICOUSBRP2350 .. nmake set "filename=PicoMiteRP2350USB" if exist "%filename%%fixed_string%%extension%" del "%filename%%fixed_string%%extension%" copy "PicoMite.uf2" "%directory%%filename%%fixed_string%%extension%" findstr /B ".heap" PicoMite.elf.map :: python ../GetHighestHexAddress.py PicoMite.hex :: cmake -G "NMake Makefiles" -DCOMPILE=HDMI .. nmake set "filename=PicoMiteHDMI" if exist "%filename%%fixed_string%%extension%" del "%filename%%fixed_string%%extension%" copy "PicoMite.uf2" "%directory%%filename%%fixed_string%%extension%" findstr /B ".heap" PicoMite.elf.map :: python ../GetHighestHexAddress.py PicoMite.hex :: cmake -G "NMake Makefiles" -DCOMPILE=HDMIUSB .. nmake set "filename=PicoMiteHDMIUSB" if exist "%filename%%fixed_string%%extension%" del "%filename%%fixed_string%%extension%" copy "PicoMite.uf2" "%directory%%filename%%fixed_string%%extension%" findstr /B ".heap" PicoMite.elf.map :: python ../GetHighestHexAddress.py PicoMite.hex :: cd .. timeout /t 20 /nobreak ren build buildRP2350L Edited 2025-11-26 03:32 by matherp |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 278 |
OK! I'll check that out for all versions in a few hours. The Debugger uses about 12Kb of flash memory. (It varies up and down a little bit depending upon the version of the firmware that is being generated.) It uses less than zero bytes of SRAM if it is not activated. If it is activated it grabs 384 bytes of SRAM via a call to GetSystemMemory( sizeof(struct Debugger_Memory)); |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 278 |
I checked everything out and I believe all 'D' versions are good. Originally, I wrote a .cpp program to parse the .map files and tell me where the FLASH_TARGET_OFFSET should be. Later, the .cpp program was modified to find all Debugger code and variables and report the size of each in all segments. Lately, I haven't even really been using that program to parse the .map files. This is for a couple of reasons. Because the Debugger uses less than zero SRAM I have only needed to be concerned about the FLASH_TARGET_OFFFSET number for a given firmware version. And assuming your numbers in configuration.c are set to good values I can quickly just bump that number up by 16 Kb. (In reality, I only need to bump it up by 12 or 13 Kb, but it was safer to go a few Kb more just because the optimization success of the compiler is hard to predict with all the veneer code that gets added depending upon code placement.) One thing I did notice in the last couple Release Candidates is that the WebMite-RP2040 isn't linking correctly. Its Ram section is 88 bytes too big. I had to adjust HEAP_MEMORY_SIZE down by 1kb for it to link successfully. I don't know yet why that is. C:/PROGRA~2/ARMGNU~1/133167~1.3RE/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: PicoMite.elf section `.heap' will not fit in region `RAM' C:/PROGRA~2/ARMGNU~1/133167~1.3RE/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: region `RAM' overflowed by 88 bytes It might be because you are using cmake followed by nmake. And I'm using only cmake: cmake -GNinja -DCOMPILE=WEB -S . -B build cmake --build build --target PicoMite I'll run down that build difference when I get a chance and figure out why things are different between the build scripts. |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 278 |
@matherp I ran down the difference with the RP2040 WebMite build. The difference is the compiler puts veneer code in SRAM to make it possible to get to functions that are too far away from the calling code. And with the extra 12KB of Debugger code inserted in the middle of the .c file list, it was adding a few too many bytes and there wasn't enough SRAM space to do what it was being told to do. I think I can just move the debugger.c file to a place that doesn't force as many veneer calls and I'll be able to use the exact same configuration.h settings as you have specified. Probably the first place to try is to move it to very end of the .c file list because there are only two calls into the debugger and they are done from MMBasic.c. Incidentally... Building with Cmake followed by nmake produces identical picomite.elf.map files as building with Cmake (generating Ninja code) followed by Cmake. The only difference is there are some back slashes instead of forward slashes in the file paths. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10681 |
This is very very bad  Flash memory can only be erased in chunks of 4K. So the HEAP MEMORY SIZE, which also determines the maximum program size and therefore the flash slot size MUST also be in set in 4K increments. Basically, every allocation of flash must be in a minimum of 4K chunks |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 278 |
OK! I am going to spend some time seeing if I can get things to link with your numbers. It was only the RP2040 WebMite that had a problem. And if I can't get that to link with your numbers, I'll adjust by 4KB and not 1KB. Thanks for the pointer! |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 278 |
PicoMite v6.01.00RC21D There are no known issues with the debugger at the moment. PicoMite_v6.01.00RC21D---Documentation.zip PicoMite_v6.01.00RC21D---Firmware.zip . |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 278 |
PicoMite v6.01.00RC22D There are no known issues with the debugger at the moment. I'll be travelling for the next week. It will be difficult to respond to new PicoMite v6.01.00 Release Candidates during this period. But if the changes in RC23 are not too complex, it may be possible to respond quickly with a Debugger version while on the road. PicoMite_v6.01.00RC22D---Documentation.zip PicoMite_v6.01.00RC22D---Firmware.zip . |
||||
| Page 3 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
