Buserror/pr m644p all working

[buserror]

So this summarizes all the latest bits, working firmware, and including a working firmware update(!) -- I'm pretty sure the flashed firmware is absolutely identical to the one that is generated, but of course, I couldn't test on a 328p real board (altho my simulated one works great!)

I've tried to be as clean as Ican, but there are some Makefile wizardry going on now :-)

[buserror]

So this PR also enable IP with ip65, but not with ftp, for reason unknown...? I added further things on my own tree, but I then find a regression (card boot to the menu just fine, but won't start 'automatically' -- it's very likely it's due to one of my 'space saving' (saved about 100 bytes from the firmware) I did since this PR tho. I'll check that after the WE tho I'm away from the II til monday.

[ThorstenBr]

Thanks, I had a look at this - at least at the first part. Using the constants instead of hard-coded bits for the pins is certainly an improvement. I've merged and pushed most of it - but still have to look at the firmware update separately.

What we should do concerning identification for the firmware update is to use an ID from the bootloader (not from the firmware). If the update fails, or the system is switched off/reset during the update, then the firmware is gone. But the bootloader is still there (in fact, if the protection bits for the bootloader are correctly configured, it's impossible to completely brick the card, so the fw update can always recover it).

I checked the minicore bootloader. It's currently using 490bytes (for the 328p). We still have a few bytes available. So adding a custom parameter to distinguish the ATmega types is not an issue. Another option would be to add the ATmega type to the bootloaders version fields (MAJOR/MINOR), since these can already be read. But using a separate parameter for ID seems a better choice. Can you make a pull request against "Dan2MiniCore" with your latest changes? You added a new bootloader binary, so you probably have changes in the sources. I would then add a custom parameter to the bootloader.

[buserror]

Thanks for merging the bits -- I'm trying to get you bits as I've worked quite a bit on it and you too, so I'm trying to get bits merged before we walk on each other toes :-) I definitely going to make you a PR on the bootloader, my 'patch' is very simple TBH, I copied the new pindefs.h to that tree and included that in the bootloader, so it shares the same macros etc...

I do agree the bootloader could/should have the ID of the card -- altho it won't have the 'features from this firmware' flags I added to the main firmware... And yes, I think we could repurpose the bootloader 'version' opcode, as really, I don't think it serves a purpose and should definitely be more useful for us. We could always save the 'spare bits' to add features later...

My tree has quite a few more bits for fwupdate, I'm going to do some more testing and push that to you ASAP before we diverge too much :-)

[ThorstenBr]

Have a look what I did to the Minicore bootloader now: https://github.com/ThorstenBr/MiniCoreDAN2Controller/commit/f73720ea54f9c721ab40716db67f32137f4fc025

Reuses the same pindefs.h from the firmware. Adds a new custom STK parameter. The value for the 328p is chosen such that the previous default value, which the bootloader would return to any unknown parameters, matches the new 328p type. So, this doesn't even change any existing (328p) bootloaders. And they will all correctly identify as 328p. It would change the 644 bootloader, of course, which returns a separate ID for the new parameter.

[ThorstenBr]

I have merged or adapted everything from this pull request. For the latest bits, I made a few changes though - and for the Makefiles I used a slightly different approach. There is almost several ways to do things, of course - also depending on taste...

• Rather than using the cc65 to preprocess the asm sources, I changed it to use the ca65's internal preprocessor. ca65 actually has an own preprocessor. It's slightly different to the C preprocessor (using .IF / .IFDEF etc instead of #if / #ifdef) but similar.
• For the Makefiles and supporting different variants: you can now provide an ATMEGA=328P/644P parameter to make ("make ATMEGA=644P") to select the target. You can also call "make 328P", "make 644P" or "make all".
• I rebuilt the 644P bootloader to include a new custom parameter to distinguish the 644P from 328P boards. The fw update utility now also has a check. So the 328P update refuses to update an ATMEGA644P and vice versa.
• I couldn't test this with the ATMEGA644P. It might just work. But I may have overlooked sth. Let me know if you noticed something.

[buserror]

Sorry was too busy to play the last couple of weeks, picking up your merge I see you've remashed it all up the 'proper' way so the merge was long, but in fact wasn't difficult.

One thing I'd mention -- I had limited the size of the flasher (hex2bin.py) to the size of the firmware (rounded) on purpose -- also I send the 'get out of programming' command to the firmware -- strictly speaking it's not necessary, but it helped a lot with my emulator linapple to 'validate' the firmware I flash is exactly the same as it expects. So it's more of a validation phase.

One thing I realized when merging is that I never pushed my latest changes, which included removing the use of 'cpp' and etc from the firmware assembly, so we duplicated work there, too bad! I've got some more change in there, including factoring some init that saves a whole 80+ bytes. I'll do a new round of testing (emulator + hardware) and push a new branch...

[ThorstenBr]

Oh, I had missed the "leave prog mode" bit. We can add that with the next merge.

Concerning size: I had adapted it to consider both - the size of the actual firmware and also the physical size of the flash. For the ATMEGA328 I set a minimum (fixed) size of 31.5KB (so the entire usable flash, without the bootloader), while for ATMEGA644 it should support larger areas - whatever the actual size of the firmware (as long as it fits in memory). For the 328 I wanted it to keep flashing the entire area. We're using most of it anyway, there is little to gain by limiting it. And by always flashing the entire area it makes sure the update utility actually supports the full size and doesn't run into linking issues with overflowing segments etc. Also, it's nice to know there are no parts with "random data" in the flash - beyond the used area.

And as a heads up: I'm probably going to replace the C component of the firmware update utility with a plain assembler one. Only contains basic stuff just as easily done in assembler anyway. And I'll extend the Makefile to also build a plain DOS 3.3 firmware update disk - so a variant which can be run on machines with 48K of RAM only. That doesn't bring any advantage to Apple II users - DAN][ is a ProDOS card, so all Apple II users have >= 64K anyway, so they can run the fw update utility from the DANII tool disk. But it finally provides firmware update support for Apple III, which is only capable of emulating a 48K Apple II system (so no ProDOS). I'm having trouble with fitting it with the C module, however. CC65 introduces various linker sections when C code is linked. And somehow it refuses to fit into 48K (with the 31.5K fw binary included). No such issues when using a plain assembler binary...

[buserror]

Ahah we we might have to diverge on the firmware updater then... as I'm planning to beef it up to support loading >32KB using the IIe aux memory to support flashing the whole 64K on the 644! I've also started a major revamp of the hardware, using a level shifter and a few other changes. One of them migth allow programming the AVR via ISP directly from the apple 2 -- I see no reason why not, I've had a piece of C to do that using GPIOs forever... so it wouldn't be too hard to even allow flashing a bootloader at least, and do the fuses before using the 'main' flasher...