File based Assembler

[BruceRMcF]

... what's not to love?

A 16-bit CPU with a 24-bit address bus weirdly hamstrung by a memory map designed for an 8-bit CPU isn't quite ideal, IMHO.

It's got a 24bit address space, to be sure, but the address bus is, in fact, 16bits ... that's why it fits into the socket.

Ever since the move to the 65C02 was made, with the possibility raised of moving back to the 65816 at some future date, they made it pretty clear that it would be with the current memory map, so I haven't worried about the memory map issue since 2018.

~~~~~~~~~~~~~~~~~

Why would you rewrite all of your code? Do you make that heavy use of the BBR, BBS, RMB and/or SMB instructions?

Yes. Lots and lots. The main loops on both Asteroid Commander and the Surreal game engine. Lots of uses in the META/L editor. The multiplication and division of FASTMATH and FASTATAN. Everything. I'd have to change around 20 thousand lines of assembly language code to make it all work without BBR, BBS, RMB, and SMB.

Oh! Ouch. Ever since they flagged that the issue of whether or not to move back to the 65816 was something to be determined later, I've avoided 65816 unsafe code, but OTOH I've only settled down to programming for the X16 for three or four short bursts.

[kelli217]

... what's not to love?

A 16-bit CPU with a 24-bit address bus weirdly hamstrung by a memory map designed for an 8-bit CPU isn't quite ideal, IMHO.

It's got a 24bit address space, to be sure, but the address bus is, in fact, 16bits ... that's why it fits into the socket.

Ever since the move to the 65C02 was made, with the possibility raised of moving back to the 65816 at some future date, they made it pretty clear that it would be with the current memory map, so I haven't worried about the memory map issue since 2018.

In the interests of strictest accuracy (this is the internet, you know), it actually does have a 24-bit address bus—it's just that lines A16-A23 are shared with lines D0-D7, each being active on alternating clock phases.

Those extra 8 address lines won't be demultiplexed or otherwise made available in the X16's CPU socket, though, so it will effectively be a sort of pseudo-65802, in practice. I would imagine that if the 65802 itself were still in production, we'd be using that.

[ahenry3068]

I've only been lightly following the 65816 discussion. Is that true about a 24 bit address bus ? !!!! Thats 16 mb of addressable RAM same as the 80286 had in protected mode (also a 24 bit address bus). To bad we can't access that...

[Ser Olmy]

It's got a 24bit address space, to be sure, but the address bus is, in fact, 16bits ... that's why it fits into the socket.

Nope, it's 24 -bit with multiplexed pins, a bit like the Intel 8086.

[ahenry3068]

It's got a 24bit address space, to be sure, but the address bus is, in fact, 16bits ... that's why it fits into the socket.

Nope, it's 24 -bit with multiplexed pins, a bit like the Intel 8086.

8086 had a 20 bit address space. 80286 --> 24 bit address space(in protected mode). 80386 --> until whenever we hit 64 bit was a 32 bit address space. (I'm not actually sure what generation Intel went to 64 bit I think maybe AMD went there first ??)

[Ser Olmy]

8086 had a 20 bit address space.

I wasn't referring to the size of the address bus, but to the multiplexed pins.

[TomXP411]

It's got a 24bit address space, to be sure, but the address bus is, in fact, 16bits ... that's why it fits into the socket.

Nope, it's 24 -bit with multiplexed pins, a bit like the Intel 8086.

8086 had a 20 bit address space. 80286 --> 24 bit address space(in protected mode). 80386 --> until whenever we hit 64 bit was a 32 bit address space. (I'm not actually sure what generation Intel went to 64 bit I think maybe AMD went there first ??)

The answer is "both." Intel built Itanium in the 90s, but it was a flop, because they went nuts and completely changed the instruction set design.

Then AMD built a set of 64-bit extensions into an x86 CPU, which really makes AMD the inventor of the current generation of CPUs. Intel had to license AMD's tech in order to integrate that into their CPUs.

And by 2006, pretty much every CPU from both companies used the AMD64 ISA (renamed x86-64 by Intel, because of obvious reasons.)

[Ser Olmy]

The answer is "both." Intel built Itanium in the 90s, but it was a flop, because they went nuts and completely changed the instruction set design.

Itanium showed all the signs of being Designed by Committee.

And by 2006, pretty much every CPU from both companies used the AMD64 ISA (renamed x86-64 by Intel, because of obvious reasons.)

They went out of their way to avoid acknowledging that x86-64 was licensed from AMD. In Intel-speak, the 64-bit x86 extensions are called "EM64T," which supposedly stands for "Intel Extended Memory 64 Technology" (funny that there's no "I" in the acronym).

[BruceRMcF]

... what's not to love?

A 16-bit CPU with a 24-bit address bus weirdly hamstrung by a memory map designed for an 8-bit CPU isn't quite ideal, IMHO.

Yeah, that's not ideal. We actually discussed ways to mitigate that (a few of us on Discord)... but those would all cause the situation Ed was complaining about. Allowing the CPU to directly control the bank registers would certainly be a breaking change.

Personally, I'd love to see some sort of interposer board that lets you add 65816-specific extended memory and which could be addressed using the 816's internal bank registers. We could even load a modified KERNAL into memory on this board with improvements for things like far get, far fetch, and far jump instructions (by putting them on 816 extended memory, rather than $A000 banks.)

Someone will end up designing a proper Commander 816, which moves to a flat memory model... but it will, of course, require heavy modifications to the KERNAL and application programs to operate.

IMHO the first step in that direction might be a a bus mastering 65816 expansion card.

________________________

A 16-bit CPU with a 24-bit address bus weirdly hamstrung by a memory map designed for an 8-bit CPU isn't quite ideal, IMHO.

It's got a 24bit address space, to be sure, but the address bus is, in fact, 16bits ... that's why it fits into the socket.

Ever since the move to the 65C02 was made, with the possibility raised of moving back to the 65816 at some future date, they made it pretty clear that it would be with the current memory map, so I haven't worried about the memory map issue since 2018.

In the interests of strictest accuracy (this is the internet, you know), it actually does have a 24-bit address bus—it's just that lines A16-A23 are shared with lines D0-D7, each being active on alternating clock phases.

That's what I'm saying ... the physical address bus ... the set of lines that carries the signals that tell the system where the data goes to or comes from ... that is assembled in the system from the information provided by the 65816.

65816 addressing is like a shelf bought from Ikea, where the last step on the assembly lines to put it together is located in the customer's house ... "oh, and can you grab this data from the data lines and put it on some lines to create the address bus yourself? I'll either have or grab the actual data quite shortly".

To be sure the 8088 is worse, it only has 40% of the address bus provided directly by the CPU, 40% assembled from information on the data bus lines and 20% assembled from information on CPU status lines. And rather than being an 8bit CPU pretending to be a 16bit CPU by sometimes operating on two bytes in sequence, it's a 16bit CPU with the 16bit data bus also offered in kit form to be assembled by the system.

Of course, it wouldn't sound impressive if they said, "well, putting the address bus together is kind of a DIY affair, good luck!", so of course they say "well, if you squint and think about it the way we want you to, there's an address bus, it's just multiplexed."

Those extra 8 address lines won't be demultiplexed or otherwise made available in the X16's CPU socket, though, so it will effectively be a sort of pseudo-65802, in practice. I would imagine that if the 65802 itself were still in production, we'd be using that.

To be sure, and though you don't have to protect an actual 65C802 from contention on the data bus during Phi1, if /OE of the selected device is qualified on Phi2 and the Phi1O pin has a pull-up resister, it comes to the same thing.

[desertfish]

Updated the assembler in the first post with a new version that has a bug fix in the .include directive.