The success of several projects in (almost) dropping in an 816 to an 02 design indicate that the address muxing onto the databus in the first half of the cycle may be no problem. Note that systems such as the Beeb and the Apple ][ use the first half-cycle for video access to RAM: all the action from the CPU perspective happens during phi2.

Hi, Ed. What you say is true but the two sentences intermix different subjects, which I fear may muddy the waters.

Yes, there are examples (such as Garth's workbench computer) where an '816 has successfully been dropped into an '02 design. Except for that I think my comments belong in the other thread.

J.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks for the clarification, BDD. When you refer to a double-access of the device, that was because the <addr>,X access was to/from a 16-bit register, and thus required two bus cycles? Just checking. If I understand correctly, even a single access would've triggered the problem, since even a single access would interfere with the 2692's need for some quiet time. (But 10 ms sounds like more than enough if the clock is 3.6864 MHz.)

To me this last statement seems at odds with the two previous. When VPA/VDA indicate no valid address, the glue logic is supposed to withhold the read enable & write enable signals used by the memory & peripherals. That being so, I don't see why it would matter if an incorrect bank address were latched, or why a WDC peripheral would malfunction. Am I missing something?

cheers,
Jeff

ps- Hmmm... Some peripheral chips don't have read enable & write enable inputs, using a R/W & Phi2 type interface instead. In that case the glue logic would need to withhold Phi2. Alternatively it could withhold the Chip Select -- which would be the best option if you didn't want to gate Phi2 because it acts as a time base (as with the 6530, 6522 and probably a bunch of 6800 series timer/peripheral chips). Both alternatives are pretty easy, and, as you say, no reason to go against the grain.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Well I still don't know yet what to do with a microprocessor, but I have been trying to get interested from my point of view.
A large Solar storm or a Bible prophesied disaster, are reasons to look into the foundations or this silicon based world, to recover better from being back in the stone age.
So I have been collecting arguments and reasons, of why the 65816 is a good computer processor:-

1. Even the Chinese who need more than 8 bits for their language, tend to use English any way, But the 65816 has a lot of 16 bit abilities good for Chinese fonts.
2. According to Bill Mensch using the Zero Page which is the first 256 Bytes of memory, for a sort of indexing of the rest of the memory, including extra registers, pages of size 64KiloBytes and for finding parts of data and programs, is the most effective way to program a machine at the binary number code level of the machine.
3. The 65816 can almost directly address 24bits of memory, which is 16.8Megabytes.
Assuming a Bible of 120 pages needs 4.5Megabytes, the 16.8Megabytes could store about 448 pages.
A very convenient size of storage by big paper book standards of past human data storage.
Which may be useful for an officer in unusual circumstances such as radio log book and contact resume.
4. Whilst many smaller processors could manage text of a book, a chance of a crash increases, as they would have to be clocked faster. Not so good to make insurance against some sort of emergency conditions.
5. Whilst many bigger computers could store much much more, they require you to store carefully in such big spaces, to find things again, and to not store what is less wanted without noticing it.
Plus both the bigger memory and processor, being bigger, could catch a critical unwanted error, just as a larger farm is harder to manage than a smaller farm.
6. Being less friendly for graphics, means the mind twist pornography, is less likely to do so.
7. The 65816 is closely related to the amateurs computer the 6502 of over 43 years of age, with still a following.
The 65816 itself in many formats of system, still is sold professionally in the millions every year in the whole world even though over 34 years old.
With enormous amounts of totally free software being findable for it, even if it may be meant to work on the 6502.

Another big bunch of reasons, which are not technical, is that it has in its make up, Biblically special numbers.
It was made and finished by Bill Mensch, the present owner and his sister Kathryn, in the year autumn 1983 to autumn 1984, the centre year of seven years ending in autumn 1987, a blessed Sabbath seventh year of those Jews who believe in it, from out of the Bible.
As a Christian my own self, I believe in the blessings from God, that He makes, every Seven years and also the Jubilee year, that happens after the seventh Sabbath seven year cycle and 2016 was the last one.
More than this 1984 was a good year for sci-fi films such as The Terminator with its 6502 processor, Repo Man, Dune, 1984, Ghostbusters, Revenge of the Nerds, Razorback. Six days of the Condor in 1974 Robert Redford searching for a safe no mans land in a silent civil war, finds a quiet spot in a telephone exchange. Shows how technology can get involved in a silent civil war of two government departments set against one another by accident of non open public policy.
The book called 1984 is among such classics as Animal Farm, Brazil, Clockwork Orange, 2001 and Brave New World.
The chip in the skin currency having come into Brazil the actual real country already, and is evolving to move more things both in and out of a persons zone of personal space, maybe one day to become the Mark of the Beast mentioned in the Bible.
1984 was chosen by the more Jewish artists to celebrate roughly 35 years (half of 70) of Jewish freedom from racism in Israel that started being an Independent State in 1948.
The 4 and the 8 being switched by the author of 1984, back around then in 1948 after World War 2.
Bill Mensch was born in 1945, that being a Sabbath year and the end of World War 2.
The year 1984 was also 140 years after 1844, a special year for the Seventh Day Adventists 2 times 7 times 10.
The chip has a high clock speed of 14Megahertz 2 times 7.
The 16 bit words added to the 24 bit address makes 40 bits and 40 is important in the new and old testament Bibles.
It is probably the only Computer ever to be sold entirely dedicated to the Bible, as an e book before tablets in about 1991, another middle year, 7 years after its birth. Even its address range 16.777216Megabytes from the 24 bits has 3 times of a 7 in it, that together are supposed to be a good number some how.

Have you got some more?
Please email me on loweruvsky@gmail.com.

(It would be good to keep this thread on-track, about the '816, so let's not follow up the non-technical ideas mentioned above.)

It's true that having a 24-bit address space provides quite a lot of space for data - a surprisingly large amount when compared to a book. I think some photo keyrings and some pocket dictionaries used 6502-like CPUs with some address extensions for this purpose. When all the data is in memory, you don't need a file system abstraction to deal with it, which makes the software smaller and easier and less power-hungry.

There was a port of BBC Basic to the '816, by John Kortink, which allows for Basic programs to use the full memory space for their data. I don't think he published the source and I don't know how extensive the changes were. I believe Basic programs are still limited to and share bank 0 with the interpreter - it's only data which gets the 24 bit treatment. (As is evident, I haven't run it, and as it happens, the hardware it was written for is no longer produced.)

I think one problem is that while there are some excellent simulators for the 6502 you can play around with -- say, py65mon -- there are still basically none for the 65816. So you can't just fire up something and fool around with it for an afternoon to figure out if you like it. Since I've really liked my experiences with the MPU, I might try my hand at a version in Go (fast becoming my new favorite language). My feeling is that would go a long way towards more acceptance.

I think you're right, having a platform to experiment and debug, and where you can add instrumentation to investigate oddities, would be very valuable. And go is an interesting language to try it in, and one which allows you easily to provide an executable for others to run directly.

(See also this previous conversation where, inevitably, I mention lib65816, but also Bruce's comprehensive '816 document.)

While '816 simulators aren't as common, for sure, they do exist. In fact very good ones exist, they just happen to be buried in video game simulators and IIgs simulators, so those bring a bit of baggage with them.

And it's not as if an '816 simulator is a major leap from a '02 simulator. I'm sure I could at '816 to my own pretty quickly, far less time than having to write one from scratch.

I think the lack of simulators is congruent with the lack of enthusiasm for the chip. Were more folks interested in it, we'd have more simulators. I don't think one drives the other. Rather they're simply projections of each other.

If anything, the real problem is that there's no software for them. Sure, you could run the 6502 version of EhBASIC on one, but that's not really a motivator to go the extra step. It's great the '816 can run '02 software, but where's the software that exploits the '816.

So, anyway, it all kind of fits together. No one reason, just a flurry of outcomes.

For me, the 65C816 is a bit of a strange device. On the one hand, it's a straightforward extension of the 65C02 to a 24-bit address space. On the other hand, it has a number of decidedly annoying quirks which make a programmer's life significantly more complicated.

The main one is that there are now *three* mode bits which materially affect the CPU's behaviour, rather than only the Decimal bit as the 6502 always had. The two extra bits actually alter the sizes of immediate operands, which means the assembler needs to be told what state to assume they're in. The D bit only affects two instructions (ADC, SBC) whereas M and X influence almost every useful instruction, so it's necessary for every routine to either set those bits on entry (and restore them on exit), or impose as a precondition that the mode is set correctly by the caller.

The address space is also described as "linear", but it really isn't. The program counter wraps around in 64KB-aligned windows, the most-significant 8 bits being set by a static bank register which can only be updated by various "long jump" instructions. Stack-relative accesses also wrap around (IIRC - or was it Direct Page, or both?). Only indexed accesses are capable of looking into the memory bank following the one initially pointed to, though you can indirect to any arbitrary address in the usual manner.

There is also no easy, fast way of adding an 8-bit value in memory to a 16-bit accumulator. You must either revert to the 6502 method of conditionally incrementing the high-order byte in zero page, or repeatedly swap the two halves of the accumulator in order to use ADC #0 on the upper half.

All of this makes exploiting the '816 properly more difficult than it should be. Like the 6502, much code is spent on housekeeping and working around the CPU's limitations, rather than implementing an algorithm. My recommendation would be to leave the index registers in 16-bit mode and the accumulator in 8-bit mode, unless you have a routine which clearly benefits from a 16-bit accumulator, much as you would leave a 6502 in non-decimal mode by default.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thx for the mention, Garth. The idea can, from one perspective, be viewed as even yet more %#!& Mode Bits and some people may accordingly view it with mistrust! But FWIW these are mode bits which can, if desired, automatically set themselves upon entry to a routine, and, on exit, automatically revert to their original settings.

Very briefly, an example: in a 1 MB system, address lines A23-A20 can be no-connects from the POV of memory decoding. IOW the memory map would feature 16 identical images of the 1 MB memory map, and any given routine could be executed from 16 different addresses -- the only difference being the state of A23-A20. To alter the "mode bits" using in-line code you'd do a JML to the next inline instruction's address, except with the desired mode bits appearing in the top four places. Similarly, you could JSL to a routine that's not inline, again placing the desired bits in the top four places. The original bits get pushed to stack, then the new bits take effect. When the routine completes an RTL occurs and the original bits get restored. Moreover, the same automatic save/restore occurs during interrupt service.

Yes, you could instead implement the mode bits as a memory-mapped output port, but to alter the port you'll likely be forced to trash a register. You'll need to reserve and decode an I/O address. Plus, you won't get the automatic save/restore that happens with a JSL (and during interrupt service, which is likely to be timing-critical).

I hardly think I'm the first to come up with this idea. But it's an interesting side note regarding the utility of the 816's larger address space. A 6502 could use the same trick, but not many applications would benefit, given how the usable address space diminishes. (Hmm, but if you only defined one bit, say, you'd still have a 32K space.) In this thread I won't elaborate regarding the wacky (and OT) uses to which I'd put these bits!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

And, to add my 0.10$, the bank is also pushed to D0-D7 during Phi2 low, even when RDY is pulled low.
So if the CPU needs to wait for a slow device, e.g. a ROM, you need to make sure the data bus has no contention between the CPU and the device/ROM.

André

Edit: I stand corrected. If RDY is low, bank is not pushed to Dx

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

fachat wrote:

And, to add my 0.10$, the bank is also pushed to D0-D7 during Phi2 low, even when RDY is pulled low. So if the CPU needs to wait for a slow device, e.g. a ROM, you need to make sure the data bus has no contention between the CPU and the device/ROM.

Contention won't occur because when the 816 (and 65C02) stops for RDY it stops when Ø2 goes high. Hence the data bus will be in the data phase, not the bank address phase. That said, use of RDY in an 816 system with extended RAM (and therefore latching the bank bits) is problematic. The reasons are discussed here.

In my POC V1.2 unit, wait-stating is accomplished by stretching Ø2 on the high phase instead of diddling with RDY. It turned out to be less difficult to implement and allowed me to run V1.2 at 20 MHz. V1.1 topped out at 12.5 MHz, above which it became unstable.

The same method will also work with the 65C02 and should work with the NMOS processors, which don't respond to RDY during a write cycle.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Just to add some more references, as the 816's multiplexed bus, and the question of RDY, are things which keep coming up:

Managing the 65816 multiplexed bus (topic)
When is a Latch not a Latch? (Capturing the '816 Bank Addr) (topic)
RDY vs CLOCK STRETCHING. Includes 2 very simple circuits. (topic)
The 65816 does NOT drive the bank address while RDY is low (post, measurement)