tom-seddon / acorn_mos_disassembly Goto Github PK

The MOS 3.50 code at $fc00 looks very similar to the Terminal-based reset code in other versions, of course...

Versions list has it as just 5.11! Should do a pass and check the names are all correct.

If no Tube relocation bitmap, the tube parasite address isn't reset to $8000: https://github.com/tom-seddon/acorn_mos_disassembly/blob/fa074c9a1426e8e6f861722f48932db02b9a9235/dist/mos350.lst#L32182

I think this might be the only thing that needs fixing?

I initially thought the rtc NVRAM code was separate, but it's all part of the same blob of code!

There's approx $500 bytes free in the utils ROM, and the 3.50 SRAM utils take up something like $3fa+$a7 bytes. It should fit!

Sadly the $a7 bytes need to go in the MOS region, as they deal with accessing sideways ROMs. There is all of 1 easy byte free in that part. So some 3.50-style rearrangement will be required.

Check for Tube hardware. Appears twice.

Would be nice to have a pre-built .lst file in the repo. If you're using the disassembly for its intended purpose, the repo is then ready to go after a git clone.

Should check that the build output matches first.

No need to force people attempting a DIY build to build the code.

These would be perfect for feature flags:

OSBYTE $6b (MOS 3.20 only):

QnD Y2K fix, so it's always 20xx:

*MOVE permissions bug:

https://www.stardot.org.uk/forums/viewtopic.php?p=413242#p413242

Actually more like withTST, I think - it sets TST and then restores it when the caller does an RTS.

Might be a bit nicer. Try it and see.

Workaround for #29 if you really want to use 3.50(NT): BASIC 4r32 with the relocatable bit clear. Then it won't matter if the relocation table is missing.

Do the same for View, ViewSheet and Edit, if necessary.

Some stuff after the default vector table. What is it?

The Welcome disk includes an Acornsoft sprite ROM, some kind of mod of whatever was in the GXR ROM. Could this be squeezed in somehow?

Could at least disassemble it for optional inclusion in some other ROM. The space freed up by the (NT) versions would be one obvious candidate, if putting together an entire MegaROM, but there are also other options.

To go in the readme or something...

1. Poke about in this repo until happy, commit result
2. Make another commit with version number in refresh.s65 incremented, and a new entry in refresh.md indicating that this is the version number now under development
3. Update acorn_mos_refreshed repo's submodule reference to the commit made in step 1
4. Push

The previous version's section from refresh.md should go in the GitHub release comment

The MOS you always wanted. NT = No Terminal. 6 banks of MegaROM free for absolutely whatever.

It should fit: Terminal = 2757 bytes; MOS 3.20 ext code = 1536 bytes, and MOS 3.50 ext code = 2304 bytes.

For MOS 3.20, nothing else to do (I don't think).

For MOS 3.50, does anything need doing with the Tube relocation tables? They look data driven, so hopefully not.

https://stardot.org.uk/forums/viewtopic.php?t=10111

Just tried to link to a line - but the file is too large for GH to render in non-raw mode!

Should split it up.

This setup has served its purpose and is no longer necessary. It would be better to remove the version-specific names and calling code changes that serve only to deal with routines that have moved from one section to another without changing their name.

Copy-pasted notes from discussion elsewhere, that needs some comments adding to the disassembly...

This bit of code here: https://github.com/tom-seddon/acorn_mos_disassembly/blob/e8e54cb2d5a108e2d79fc1734fceaa8b5f199180/src/terminal.s65#L3182C71-L3182C71 - it can actually detect whether the EEPROM read succeeded (the chip puts out an acknowledge signal that you can read), and, if it didn't, it can return a default value from the table L9DE4.

The Compact MOS can also support either a 128 or 256 byte EEPROM. When resetting the CMOS data, it EORs the value in location 127 and writes that to location 255. So locations 127 and 255 are either different (256 bytes) or the same (128 bytes):

You can query the EEPROM size by reading EEPROM address 255: https://github.com/tom-seddon/acorn_mos_disassembly/blob/e8e54cb2d5a108e2d79fc1734fceaa8b5f199180/src/terminal.s65#L3162C31-L3162C31

I can't quickly find any official docs about this, but BeebWiki mentions it: https://beebwiki.mdfs.net/OSBYTE_%26A1

What it doesn't mention is that you can't write to EEPROM addresses 0, 127, 128 or 255:

Still, the only documented CMOS/EEPROM addresses are 30-49, so not really a big issue.

Bit pointless.

The bank switching is done via an EOR, so only the relative positions are important. Provide more pairs of modified ROMs, with different EORs, so that you have more options.

Oops

Should really be called NVRAMContents or something, as it might be EEPROM!

Squeeze out a bit more speed in the common case. In my quick test of LISTing a 200-odd line BASIC program, the LIST took 0.95 the time. Insert before this line:

                ; Early out when doing VDU output only.
                lda characterDestinationStatus
                beq LE8A5

Building each ROM takes 4 passes! Does it need that many? Doesn't take too long, but, still...

Tried rearranging the driver files a bit, so version= comes first and the .dsection directives are last to reduce the amount of out-of-order stuff. Still 4 passes.

Noticed some more here: https://github.com/stardot/b-em/tree/master/roms/os - anything new there?

Looks like default CMOS RAM contents. So it should be expressed a bit more obviously, rather than just as a list of random hex values.

There's enough free bytes, but those free bytes are not in the right places... yet...

It's from here: http://www.adsb.co.uk/bbc/bbc_master.html

Link is to non-existent https://github.com/tom-seddon/acorn_mos_disassembly/docs/refresh.md

The listing file is workable, but it could be a bit tidier. The format is fairly regular, possibly regular enough to produce a useful HTML file from it, with cross-references and so on.

It probably won't be as nice as https://tobylobster.github.io/mos/ though :(

There's a pic of this on beebmaster's site but I can't find it now I'm looking. Might be an easy fix?

Well, obviously it's utils. But you'd never guess from the code. Or the file names.

1. make relocatable ROM non-relocateable
2. extract bitmap (requires relocatable ROM + bitmap ROM)
3. add bitmap metadata (requires relocatable ROM to modify + bitmap ROM to append to + bitmap ROM bank number)
4. modify bitmap metadata (requires relocatable ROM + bitmap address + bitmap ROM bank number)

Timings taken on Master Turbo.

*BASIC on MOS 3.20: ~0.22 seconds
*BASIC (which, for whatever reason, skips the relocation step) on MOS 3.50: ~0.41 seconds
*FX142 12 on MOS 3.50: ~0.60 seconds

Issues with the MOS 3.50 code:

1. it doesn't have a MOS 3.20-style fast path for the case where there's no relocation data
2. it copies relocated ROM data to an intermediate buffer, then sends that using the Tube pagewise transfer mode. But since it's only doing 256 bytes at a time, surely it could just use the Tube pagewise transfer mode directly!
3. the relocation code could be improved a bit if it could be copied to RAM, permitting some self-modification (there's space in page 7 if not buffering the result...), and if it could assume the language ROM definitely needs relocating