BillG wrote:
cjs wrote:
BillG wrote:
If you cannot tell, I am still trying to justify making an identity table an included feature in FLEX. Every time I think I need it, I find a way around it.
My instinctive reading of this is, "I am trying to find a reason to give the user 256 less bytes of free RAM. :-/
That is the feeling I get too. It is a case of "if it was already there, I would use it, but I will not choose to make the sacrifice."
That is the motivation to ask those who have written more 6502 code than me...
Nothing to do with FLEX, but just a thought in-general. Way back when the BBC Micro was launched a criticism at the time was that it only had 32KB of RAM. This was in 1981 when the Apple II had 48KB (really 64KB by then). Both used RAM for video - the Beeb needs a whopping 20KB for "mode 0" which is a high resolution 640x256x1 display.
Digging deeper, or just got worse. The bottom 15 pages (3840 bytes) of RAM is used by the operating system and BASIC. Nearly 4KB! That's on-top of the 16KB BASIC ROM and the remaining 16KB being used by the OS ROM and IO space. Add a filing system ROM and that took up more lower RAM (ROMs are allowed to claim low-RAM, it's designed into the OS) So the more ROMs (mostly filing system/network ROMs) you added the less RAM you had for BASIC, word processing, etc.
But once we got over the seemingly lack of RAM we just got on with it. I wrote (and sold) programs for it, used Beebs to develop the basis of a flexible manufacturing system using their networking capabilities and the boffins at Acorn HQ went on to develop the ARM processor using it, and it didn't stop Elite being developed either.
Today, RAM is cheap, so when I started my Ruby project I stuck 64KB of RAM in it and didn't even think about trying to optimise my code for size. I just coded freely without that constraint. My OS is about 10KB and mimics the Acorn one without the graphics or multiple ROM support or sound or printer or a few other things I've probably forgotten. But it does have a nice CLI with editing and history and verbose error messages and a nice interface to the filing system though... If I load up BBC Basic or EhBASIC (which both live from $8000 in my system), it has usable RAM from PAGE (lomem) = $0E00 through $7FFF. Is anyone really going to write a program to use all that RAM today? Unlikely...
It also has a Sweet-16 interpreter in it which I re-wrote to be position independent and much faster than WOZs one. I initially used it to write a memory allocator in, but subsequently removed that code. The Sweet-16 interpreter is still in the OS image though and I'll remove it, if I ever need to.
So I think I'm saying that worrying about 256 bytes right now isn't (shouldn't) be an issue. Put it in and if you use it, then woo-hoo. And if at some point in the future you really need the RAM and haven't used it (or only used it once or twice), then work out how to remove it, if you really need to. There may be a question of
historical accuracy though. Is that a thing?
However, I've been looking at these (Identity tables) for some time, but haven't found a use for the extra pseudo functions it can give me - yet - but if I do, then "losing" 256 bytes? I don't think I'll notice it.
Cheers,
-Gordon
_________________
--
Gordon Henderson.
See my
Ruby 6502 and 65816 SBC projects here:
https://projects.drogon.net/ruby/