I don't play the lottery, as a matter of principle. But if someone I trusted
bought me a lottery ticket --
It would have to be someone I trusted who bought me the ticket, because "free"
money does things to people.
If it were someone I didn't trust, I would have to waste a lot of time and
probably most of the winnings buying off the interest of the giver of the
ticket.
Money always comes with obligations. It's an economic principle. It's in the
nature of what money is.
You can never really have "free" value. Value must be generated, and
generating value incurs obligations.
Rich people simply ignore the obligations, saying they know better what to do
with it, burning their charisma to get room to exercise their own will on the
value.
And money is a (poor) proxy for value.
And I have never been able to simply ignore obligations when I had any means
to respond to them.
-- So, if someone I trusted bought me a lottery ticket, and it hit a jackpot,
what would I do with it?
(This is hypothesis contrary to fact. It ain't gonna happen. But what you do with your free time, what you do with your excess, that's what defines you as a person. That's what demonstrates your true priorities. So what I'm doing here is thinking about what I'd do if I had excess. I'm trying to figure out my current priorities.)
First, I'd make sure my taxes and national retirement/social security
obligations would get taken care of. Then I'd pay into as much retirement
funds as the tax laws allow, both for myself and for my wife. Then I think I'd
pay off my children's school loans. Maybe I'd have enough to fund them in
going back for advanced degrees. Maybe I'd invest some in the companies they
work for. Maybe I'd send my wife to Europe to study nutrition and cuisine.
Family obligations.
But that is not what this is about.
If I had a lot of wealth to use as I saw fit (hypothesis contrary to fact in
so many ways), I would use it where I think some gaping holes in our society
exist, where I think I could apply myself in meaningful ways.
It would be tempting to provide extra funding for various Free/Libre
software:
But even just ten thousand here, a hundred thousand there, and a million over
there would tend to fritter the money away, so that would not be the first
thing I'd do.
It would be tempting, and useful, to start my own distributions of Linux and
*BSD operating systems. But, again, it would be easy to try to set up a
competitor to Ubuntu and Apple, and that would definitely be an easy way to
fritter money away.
It would be tempting to start an English as-a-foreign-language company doing
it the right way. So many ways the current approach to teaching English as a
foreign language are just fundamentally wrong. But it would be a hard sell,
and if I succeeded in the sell, Japanese copycats would spring up all over.
That might not be a bad thing, but it would burn money.
It would be more than tempting to start my own social media service, with a
fundamentally different business model. Or perhaps buy
OSDN for the infrastructure.
But focus on making it reasonable for the customer to own their own
- domains
- servers, including mail, authoring, financial transaction, etc.
- authoring and archiving tools
- publishing
and to provide a base community for the customers to reach out from. But I'd
basically be trying to take on Google, even if I'd be doing it right as
opposed to them. And if I succeeded, I'd have to fight off Microsoft's
attempts to buy me out and/or to embrace and extend me.
I'm getting old. I don't have time for all of that.
I have
lots of novels
I'd really like to finish and publish. That would not take nearly as much
money.
And one thing I'd like to do before I die, if I could somehow arrange the
money and time, is to define extensions and revisions to my four favorite CPUs
Wait. Why is the 6847 in this list? It's not a CPU. It's a video display
generator -- a VDG. (I will explain.)
But, why? you ask. You think you understand why I want to avoid Intel x86 and
AMD64, but we have ATmega and ARM. They're cheap, can be had in a variety of
small, medium, and large packages, and they can be programmed in C and other
high-level languages.
But you need the high-level languages. ATmega, ARM, RISC-V, and other modern
CPUs are hard to work with at the assembly language level. Sure, they have a
lot of development tools to help, but you don't want to work on them without
the tools. That means you really don't understand what's happening at the low
level. You only think you do, and I don't think that's a good thing.
Motorola's CPUs were easy to work with at the assembly language level. Maybe
too easy. But it is actually possible for ordinary people, with a little
coaching, to read the assembly language source code and get an idea of what's
happening in the code. Other CPUs, especially modern CPUs, not so much.
The one problem with Motorola CPUs is that they each had small design flaws
that meant that, as you extended and redesigned your product, you eventually
hit walls. And getting past those walls meant using programming techniques
that made it hard, again, to understand what was going on.
The 6847 VDG was similar. it was really simple to design display controllers
with it and it was really simple to program. It was great for getting output
on an ordinary TV (back when more homes had TVs than telephones). Which meant
you didn't have to buy an expensive monitor to get output from a computer that
used one.
But the display window was small, barely large enough to display even a small
paragraph of text. And Motorola never extended the design. (Radio Shack/Tandy
did, but that was too many years down the road.) (Oh, well, actually, Motorola
did do some design work to extend the 6847 design, a couple of years after
they should have, and in the process of trying to play catch-up, the design
ended up overkill, too expensive, and too hard to design for and to test. I'll
have to try to remember to link something about that here, next time I see the
relevant pages out there on the web somewhere.)
|12345678901234567890123456789012|
+--------------------------------+
1| HOW SMALL WAS THE DISPLAY |
2|WINDOW ON 6847-BASED DESIGNS? |
3|THE ABOVE PARAGRAPH WOULD NOT |
4|FIT IN A SINGLE SCREEN. AND THIS|
5|PARAGRAPH ALONE WOULD TAKE |
6|ALMOST HALF THE SCREEN. |
8| |
9| THE SCREEN SHOWED EXACTLY 512 |
10|8-BIT CHARACTERS. THAT'S 16 |
11|LINES, EACH 32 CHARACTERS WIDE. |
12|THE ASPECT RATIO WAS BETTER THAN|
13|WHAT YOU SEE HERE, SINCE THE 32 |
14|CHARACTER WIDTH SPREAD ACROSS |
15|MOST OF THE TV SCREEN, GIVING |
16|CLOSE TO 4:3 WIDTH-TO-HEIGHT. |
+--------------------------------+
|12345678901234567890123456789012|
That's a tight screen.
And lower-case characters were not available in most 6847
designs until about 1985, unless the design included an external character ROM, or unless you switched to graphics mode and wrote all the bits for each character to the screen yourself.
The 6847 was great in 1979 or even 1981. Not so great in 1985.
This is really what I mean by flaws and hitting walls. Motorola could have
extended each of these, so that the walls could be easily gotten past by the time the average user was hitting them.
Wait. If you are familiar with the 68HC- and later series processors,
you are saying, but Motorola did exactly that.
Well, yes and no. Except for the 6805 series, Motorola was always on the trailing edge of the market window. They were too slow in extending the designs. And when the
entire industry took a hard right turn and ran off into the weeds on the
question of where to store parameters, Motorola just ended up following, in spite of the fact that the designs of the 6809 and 68000 were such that it didn't need to happen.
Which is where I want to focus on in my attempts to redesign these.
6805:
The original 6805 could only use the hardware stack to keep return addresses. If you wanted a parameter stack, you had to do that as a software stack, and that meant juggling the software stack pointer with whatever you might have in the X register. Used time and code, and required you to be really careful about interrupts.
So I want to give the 6805 an additional stack, moving the return address stack out of the direct page (the first 256 addresses) and replacing it there with the parameter stack.
Motorola sort-of fixed this in upgrades to the 6805, the 146805 series and the 68HC05 and 68HC08 series and beyond, but what they did was just allow parameters and temporaries to be mixed with return addresses on the return stack, which is exactly where the entire industry veered hard right. It's a dangerous practice. (You can easily end up trying to store return values on top of return addresses and trying to return to data instead of code, and this is exactly one of the easiest places for bad actors to hack their unauthorized way into your system.) And it ends up a bottle-neck in code, since the code has to continually tip-toe around the return address.
Other obvious extensions --
Extending the X register, as is done in the 68HC08, is useful, but not the first lack I'd address.
Also, adding the ability to index off the stack pointer, as is done on the 68HCS08, is very useful, but I'd do that to the parameter stack, which means the parameter stack comes first.
6801:
The 6801 inherited its pushes, pops, and so forth from the 6800, with which it is object-code compatible, which means a single mixed stack unless you want to synthesize a software stack. Being able to push the X register on the return stack helped a little when using software stacks, but it really needs a separate parameter stack as well.
In addition, the 6801 has an add B to X (ABX) instruction which is sort-of useful for accessing fields in records and such, and for deallocating large stack frames, but it doesn't have the matching subtract B from X (SBX), which would have been useful for allocating stack frames.
Furthermore, the unary instructions on the 6801 (like the 6800) do not have direct-page address mode opcodes. If you want to increment or decrement a counter in the direct page, you have to settle for using extended (or absolute) mode, which takes six cycles instead of four, so you end up preferring to pull counters into X or an accumulator instead of fully utilizing the instruction set.
These are the three flaws in the 6801 that I want to fix. They are not even addressed in the 68HC11.
Giving the 6801 wider addressing is definitely a useful feature. This is addressed in the 68HC16, and I think I might address it in my upgrade to the 6801, but, where the 68HC16 gets only four extra bits of indexing (for each of its index registers) and four bits to extend the extended (absolute mode), I'd tend to add an eight-bit extension register for the X register and for the extended addressing mode. I'm not sure whether I'd add eight bits to either stack register, since it doesn't seem too unreasonable to keep both stacks within the first 64K of address space.
6809:
The 6809 has direct-mode unaries and two stacks. It's almost perfect. But it has a funny omission in the indexed-mode addressing modes. Where it is able to use an indexed mode to do memory indirect addressing on extended (absolute) mode addresses, there is no such indexed mode for the direct page. That means that indirection through pointers saved in the direct page must be done by explicitly loading the variable into a precious index register. It also means that taking the address of a direct-page variable can't be done with just a LEA instruction. You have to use three instructions, to bring the DP register into the A accumulator, move the offset into the direct page into the B register, and use LEAX D,X or likewise the Y index.
This severely limits the use of the direct page register as a base for per-process static variables, which is something you really want in processors as capable as the 6809.
I'd definitely widen addressing on the 6809 by 16 bits, either by 32-bit segment registers (similar to the 8086's segment registers, but done right from the outset) or by simply adding 16-bit extension registers similar to the 68HC16's four-bit extension registers. But that's less a design flaw and more an extension feature.
I could then create a true 16-bit version of the 6809 as a follow-up, but not the way it's done in Hitachi's unofficial 63C09 extensions. Those are rather haphazard, and ignore the design of the 6809, tending, rather, to make it look more like the 8086.
68000:
One flaw in the 68000 is in the exception stack frames. This is fixed in the 68010.
But another flaw in the 68000 is that constant offsets in indexing are limited to 16 bits. This means that relative branches and module tables have a natural limit of plus/minus 32K addresses, which becomes too tight when modules exceed 32K in size. Getting around that requires using an address register, which is not completely bad, but it does tend to discourage good programming practices. This flaw is not addressed until the CPU32.
The flaw in the 68020 is excessive complexity, which is why I would not go that direction. Actually, the CPU32 might be sufficient, by which I mean I would not really need to do anything in particular about the 68000.
6847:
Extensions to the 6847 include gradually more capable versions. Sprites are not necessary for every application that wants 64 characters or more per line or 512 by 384 graphics modes, more colors, lower-case characters, etc.
Also, since I'd want to use these in modern devices, I'd want to add circuitry to directly control LCD or OLED displays.
Tools:
All of these need developer tools -- assemblers, compilers, debuggers, emulators, hardware design tools, and such. Tools also take money to develop.
Conclusion:
If I were making enough at my current job, and had the energy left over at the end of the day, I could work on my novels, or work on a 6805 emulator. I shouldn't really need to win the lottery to do that. If I had the energy. If I were making enough at my current job.
What I probably need to do instead of daydreaming about this kind of stuff is figure out how I can teach private English classes during my days off.
Posts
