Problem building "the whole shebang"
This is really meant for billw, but the answer might be more widely helpful. I am trying to create a set of S records and makefiles that can be used to create a perfect replica of the original firmware. I have managed to extract the S records, but I'm having bit of a problem with the linking. Since the linker can really only handle the core, and one bank at a time, I have taken to linking each bank separately - and then using copy /b to piece them all together. This would work, except that some routines in the banks look for locations in the core (such as L0090 and L0000). I can fish out L0000 by replacing the call with an RTS, though this is technically not the same as the original firmware. However, if I try to deal with the memory init function at L0090, I end up with an extra copy of the function at the beginning of each bank - which throws things off, since I'm not linking the final binary. It seems like a really need an linker which understands banking - at least the banking scheme implemented on the PV2. I suppose I can attempt to create a "ghost" function - but even that will offset everything in the banks by 1. Any ideas?

Found another potential issue - and a potential fix for the previous problem. I can get around the jumps to regions outside the current bank by using .DB and the appropriate machine language. Ugly, but functional. Now, however; I'm running into a problem with the offset calculation. In bank 4, there is a branch which has -125 byte offset. The linker is grumbling because it thinks the offset is greater than -127. I suspect a bug - because I manually calculated the offset, and it is within the bounds for an 8-bit offset.

Good call on the .DB workaround radarman. Other than that, I don't see a neat way out without adding a whole bunch of code to the assembler. I'll take a look at the offending code for your other bug and see if I can't get a fix out for this weekend. I had intended to put other fixes and examples out earlier, but then the camcorder hack hit...

I think I can help you out. The offending branches are EXACTLY -127. It looks like you may have a greater than or equal, where you really want a greater then (or, in this case, less than?) I checked both branches, and they were $7f apart. I think I found "the bug" in write.c: /* relative 8bit with a label */ else if (r->type == REFERENCE_TYPE_RELATIVE_8BIT) { i = (((int)l->address) & 0xFFFF) - r->address - 1; if (i < -127 || i > 128) { fprintf(stderr, "%s:%s:%d: FIX_REFERENCES: Too large distance (%d bytes from $%x to $%x \"%s\") for a 8bit reference.\n", get_file_name(r->file_id), get_source_file_name(r->file_id, r->file_id_source), r->linenumber, i, r->address, (int)l->address, l->name); return FAILED; } mem_insert_ref(x, i & 0xFF); } Note that there is a hard -1 (which I assume is a fixed offset due to the way the program counter works on this architecture) used in the offset calculation. This works great for the positive case, but no so well for the negative case - where it makes you "more negative". I think this can be fixed by changing the the -127 to a -128. Comments?

Ok, the linker is fixed - I took out the -1 in the offset calculation. (well, I actually left the calculation alone, and changed the if statements). I -*test*-('")ed it, and everything seems to be working correctly. I also have my "ready to assemble" version of the 6550/2B firmware as 10 S records, and a make script. I am now getting a bit for bit identical binary out. This will greatly help in adding and removing features. The only trick is adjusting the checksum? Will pv2tool do this automatically, or will I need to write my own checksum modifier? Also, I wonder if the bootloader is expecting a certain size file - or will it load any size file? Fortunately, there are plenty of library functions that aren't being used in all banks - which could be eliminated to make room for other stuff. Need to do more experimenting...

Congrats radarman - nicely done! PV2Tool will adjust the firmware checksums for you, but it does so at fixed locations. It's unknown how the bootloader will react to a different sized firmware. It may expect checksums at different places, or it may just leave you in double beep bootloader because of the size discrepancy.

Well, you do have a bunch of unused space, and a lot of library functions that aren't being used in every bank. (it seems like the compiler included the 32-bit math functions in every bank, even though most banks only need, at most, the 32-bit add and compare. Now that I can mess with source assembly, I can just remove and replace. Be careful, though - there are a lot of hard coded links to specific variable locations. I plan to replace these with actual variables - which can be remapped - but I haven't gotten that far yet. Most variables can be "moved" around like this - EXCEPT for the ones in the core. Yes, the code in the banks directly reference variable locations in the core BSS area. This last restriction can be lifted to, but I will need to create a .inc file with all of the BSS variables from the core - which will be included in each bank. If you do remap - remember to change the BSS init routines - they will need to point to the new region of memory as well. The "next" version will be much more flexible about relocation - but I'm just glad it "assembles without error"! :lol:

Well, it's a work in progress, and I still don't fully understand all of the implications of relocation, but if you would like a copy of my work in progress, PM me with a real email, and I'll forward you a copy of the current files. I'm current documenting bank0 - making adjustments for the 6550. Lots of good stuff in there - the default NVRAM.DAT and file pointers, for example.