I've now done this. I find this stuff quite fun, so I did several versions in one - sounds like you've already looked at the other Master-specific versions, so I didn't bother trying to comment the extra stuff in 2.25/2.29/2.45, but I was interested in at least sizing up the differences. I probably wouldn't have started on 2.29 if I'd realised there was going to be that huge lump of extra OSARGS/OSGBPB stuff, but at that point I was determined to continue, and it did make 2.45 pretty easyBearing in mind you'd also have to make it use main memory, the keyboard links and the different SWRAM layouts of the B+, it'd be easier to mark up a disassembly of 2.26 and import the features you want.
GH repo here: https://github.com/tom-seddon/acorn_177 ... isassembly
I think it looks like a B/B+-friendly version of 2.24a would be quite feasible. There's not much that's 65c02-specific in 2.24a and you've already got the _NMOS flag to cover that. It doesn't look like there's much involved in putting the fixed workspace in main RAM other than making the base of it $0e00 and responding to the appropriate service call. Private workspace can already exist in main RAM as the ROM has to handle HAZEL exhaustion. The FDC and latch addresses are constants, easily changed. The latch bit differences only affect one table.
Other things I noticed in 2.26 while doing this:
1. B+ SRAM support: there's a bit of code to handle 32 KB of sideways RAM that can either be in banks 12+13 or 14+15
2. SRAM 1.05+ fixes: the command parsing got rewritten, which doesn't feel very urgent! But it's a bit tidier about its ZP usage (it doesn't use romptr as working storage...), and the Tube transfer timings have been reduced
3. extra * commands: the Master MOS provides *CLOSE, *DELETE, *EX and *INFO, but 2.26 includes these itself. Extra code and extra command table entries
4. UTILS: the Master MOS provides *DUMP, *LIST, *ROMS and *TYPE, but 2.26 includes these itself. Extra code, extra command table entries, and some extra *HELP stuff
5. Tube host: this is self-contained and just needs to hook into the service call chain
6. B+ fancy startup message: this is self-contained and just needs to hook into the service call chain
Initial thoughts about these follow. One of my goals is to minimize changes to the disassembly, the idea being that you could make some one-off changes, then I could do some kind of BeebAsm file that sets some constants and INCLUDEs the latest DFS 2.24a source and then adds in any additional stuff necessary (fancy B+ startup message, Tube Host code, extra patches).
Not sure about how interesting point 1 is. I wonder if the intersection of pseudo-addressing users and link S13 adjusters even exists? I'd be slightly tempted to just discard this altogether, and say that B+ pseudo-addressing works with 0/1/12/13 only. Then it's just a question of adjusting the RAM banks table, and the Master code would be fine as it stands. (For BBC B users: I'm not sure DFS 2.26 never supported this particularly well, as banks 0/12 and 1/13 are potentially aliases, though of course non-pseudo addressing would work fine. I think it'd be fine to leave this as-is and think about it later. If we're producing new builds, we could just produce a new B-specific build that doesn't support pseudo-addressing at all.)
2 could probably be ignored... maybe? I haven't gone through the code very carefully, but comparing the B+ app notes (referring to rewritten 2.25+ code) and the Master manuals (referring to 2.24 code), it doesn't sound like there's any obvious changes. If there is actually something useful here, it could surely be rolled into the _BUGFIX define.
3 and 4 might require inline patches. But maybe there's some way of hooking in to the service call routines, so this could be patched in externally with few/no code changes?
5 and 6 would be possible to do with no code changes, I think. JGH has already done a relocatable sideways RAM module for the Tube host code, and I think the fancy B+ startup message would be a suitable candidate for the same treatment. So these could be inserted into the ROM after the fact.
Just thinking out loud at this point. My B+ is still dead, waiting for some ICs to arrive, and I'm not going to do much more on this until it's working again.
--Tom
Statistics: Posted by tom_seddon — Sun May 26, 2024 1:21 am