POC Computer Version One

[BigDumbDinosaur]

BTW, some of the posted WDC data sheets are out of date.

[dclxvi]

BigDumbDinosaur wrote:

dclxvi wrote:

Unlike non-writing instructions (LDA, AND, CMP, etc.), STA abs,X always takes 5 cycles whether it crosses a page boundary or not.

Really! In which data sheet did you see that? Here's an excerpt from the W65C816S data sheet

See note 4, table 5.7 (addressing mode 6a, cycle 3a). The "or write" phrase means STA abs,X (and STZ) always take 5 cycles (for 8-bit accumulator, i.e. m flag = 1, which I forgot to mention in my previous post.) (The fact that STA is listed twice isn't important, though ) For the reason BigEd mentioned, STA (zp),Y always takes 6 cycles (again, for 8-bit accumulator). In both cases, 16-bit accumulator (m flag = 0) takes an additional cycle. STA (zp),Y also takes another additional cycle when DL is non-zero.

If memory serves, the Apple II 5.25" floppy driver actually depended on STA abs,X taking 5 cycles when a page boundary wasn't crossed.

[BigEd]

dclxvi wrote:

See note 4, table 5.7 (addressing mode 6a, cycle 3a).

Well spotted! I've corrected my earlier post where I cast aspersions on the datasheet - in fact this detailed table even tells us what to expect on the bus cycle-by-cycle, even in "Internal Operation" cycles.

BDD was evidently looking only at table 3-1, the summary table.

[BigDumbDinosaur]

BigEd wrote:

BDD was evidently looking only at table 3-1, the summary table.

Right you are. BTW, here's note 4 from table 5-7 concerning $ABS,X:

4. Add 1 cycle for indexing across page boundaries, or write, or X=0. When X=1 or in the emulation mode, this cycle contains invalid addresses.

Note the comment about invalid addresses. That was what was screwing up my writes to the DUART with STA $ABS,X. After I changed the logic to qualify device selection with VDA and VPA, it worked without a hitch. Currently, I'm running the '816 in 'C02 mode.

[BigEd]

BigDumbDinosaur wrote:

Note the comment about invalid addresses.

But we don't have to be frightened. The behaviour of the machine is predictable and even specified. What you had was two back-to-back accesses which your peripheral couldn't deal with. Knowing that, you had several options:

• - change the logic to avoid accessing on the dead cycle
  - change the clocking so the back-to-back accesses were not a problem
  - index from the previous page so the unwanted access does not select the peripheral
  - avoid indexed accesses to sensitive periperals

For future adventurers, it's useful to know that these choices are available. Sometimes the software fix will be preferable, sometimes the hardware fix.

While VPA and VDA can be very useful especially in a sophisticated system, I'm anxious that the beginner can have confidence in making a simple system without worrying about them.

Cheers
Ed

[BigDumbDinosaur]

BigEd wrote:

BigDumbDinosaur wrote:

Note the comment about invalid addresses.

But we don't have to be frightened. The behaviour of the machine is predictable and even specified. What you had was two back-to-back accesses which your peripheral couldn't deal with. Knowing that, you had several options:

• - change the logic to avoid accessing on the dead cycle
  - change the clocking so the back-to-back accesses were not a problem
  - index from the previous page so the unwanted access does not select the peripheral
  - avoid indexed accesses to sensitive periperals

I used number 1: change the logic. It proved to be trivial—cut a couple of chip legs and add a few pieces of wire. This arrangement guarantees that I/O device selection will only occur when the '816 is actually emitting a valid address. On my next design I will extend this feature to RAM access as well.

What was interesting was that while the DUART was clearly unhappy with the address bus diddling that was going on during the intermediate cycles of the STA $ABS,X operation, the watchdog apparently wasn't in the least perturbed. Be that as it may, my patch affects the 74AC138 decoder, which assures that neither watchdog or DUART will be selected until A0-A15 are stable.

Quote:

For future adventurers, it's useful to know that these choices are available. Sometimes the software fix will be preferable, sometimes the hardware fix.

While VPA and VDA can be very useful especially in a sophisticated system, I'm anxious that the beginner can have confidence in making a simple system without worrying about them.

Qualifying access with VDA and VPA is not at all complicated. The logic equation is simple:

Code: Select all

valid_data_memory = VDA & !VPA

Here's how I did it in my design. A more generalized approach could be used that affects the entire system, but I/O hardware is where I'd think most of the trouble would appear.

Monkeying with the clocking would actually be more complicated—more silicon would be needed, and would exact a performance penalty, not to mention possibly raising issues with hardware timers driven by Ø2. Also, any software workaround, e.g., indexing from the previous page, would make for possibly obtuse code. STA DEVICE,X makes more sense to the casual reader than STA DEVICE-1,X with .X adjusted to deal with the address shift. Also, that approach wouldn't be practical with software that accesses I/O hardware via STA ($ZP,X).

As for avoiding device access with STA $ABS,X, that would be okay if only a few registers needed to be set up or if the device had only one channel. If more than a few registers have to be configured, however, the resulting linear code would be wasteful and harder to maintain. It gets even more onerous if the device has multiple channels. For example, the NXP 2682B octal ACIA has four times as many registers to configure as the DUART I'm using in my design. Done in linear code, it would stretch for several pages and would be a nightmare to organize. Organizing the registers and associated parameters into data tables makes more sense but requires the use of some kind of indexing to select the correct device registers.

My opinion is, since WDC provides the VDA and VPA outputs to tell the system when the MPU is ready to access hardware, those outputs should be used.

[Mike Naberezny]

BigDumbDinosaur wrote:

BTW, some of the posted WDC data sheets are out of date.

Could you let me know which ones? I'll update them.

Thanks,
Mike

[BigDumbDinosaur]

Mike Naberezny wrote:

BigDumbDinosaur wrote:

BTW, some of the posted WDC data sheets are out of date.

Could you let me know which ones? I'll update them.

Thanks,
Mike

W65C02S
W65C816S
W65C134S
W65C256S

Note that the PDF posted at WDC for the 'C02 says January 14, 2009 on the title page. The copyright notice, however, is dated 1981-2010. I notified WDC about the discrepancy.

[kc5tja]

WDC is not known for their literary or technical writing expertise, that's for sure. I remember, back when playing around with my Kestrel-1 project, having numerous errors in their documentation. Lord knows, I probably could have written a superior set of timing diagrams in my sleep.

[BigDumbDinosaur]

kc5tja wrote:

WDC is not known for their literary or technical writing expertise, that's for sure. I remember, back when playing around with my Kestrel-1 project, having numerous errors in their documentation. Lord knows, I probably could have written a superior set of timing diagrams in my sleep.

The documentation malarkey seems to be a long-standing problem there. In late 1991, I was commissioned to scratch-write a real-time OS and ROM-resident M/L monitor for a 65C02-based system. The first cut of the hardware had a number of problems with memory corruption and devices not working (one of which was the Signetics SCC2698B octal UART, the big brother to the DUART in my POC unit). The glue logic was implemented in a pair of GALs, and due to incorrect information in the 'C02 data sheet, the timing was messed up when accessing RAM (implemented on 30 pin DIMMs) and I/O. I was going nuts trying to debug the code, thinking I was the culprit. I damned near wore out my EPROM burner in the process. The guy who designed the board eventually resorted to building a reference design just to examine the 'C02 timing. Much of what he found was at odds with the data sheet. Once the GALs were fixed to reflect what the MPU was doing, the system was as solid as the Rock of Gibraltar.

Speaking of documentation, the programming manual WDC has posted on-line is way out of date and a typographical mess. One of my little projects for slow days is a complete edit of the manual, mostly to get rid of NMOS 6502 references, as well as fix code examples that are out of compliance with WDC assembler syntax. Following that, I'll re-typeset it so it doesn't look like something from Microsoft Word. Dunno when it'll get done, as doing secretarial work isn't my favorite thing.

[kc5tja]

I can't imagine spending one day per page is any great burden; if that path were taken, you'd probably be able to estimate its completion at about two years hence.

But, I hear you. I've thought of doing the same thing, even taking the one-day-per-page approach, and nothing as of yet has come from it. Heck, I still haven't finished the core OS (Forth, allegedly one of the simplest of languages and environments to get working, still eludes me for reasons unknown to me. Bizarre, since I have written an x86 Forth implementation once before) of the Kestrel-2 design (although I do have a crude software emulator written for Linux for it).

[BigDumbDinosaur]

kc5tja wrote:

I can't imagine spending one day per page is any great burden; if that path were taken, you'd probably be able to estimate its completion at about two years hence.

But, I hear you. I've thought of doing the same thing, even taking the one-day-per-page approach, and nothing as of yet has come from it. Heck, I still haven't finished the core OS (Forth, allegedly one of the simplest of languages and environments to get working, still eludes me for reasons unknown to me. Bizarre, since I have written an x86 Forth implementation once before) of the Kestrel-2 design (although I do have a crude software emulator written for Linux for it).

In 2006, the father of a friend of mine died at the age of 89. When I was asked to speak at his funeral, I repeated something he had said the year before his death, "Don't run out of projects or you'll die an early death." He was a life-long modeler of ships and was working on a model of the USS Lexington (the World War II carrier) when Old Man Time finally caught up with him.

I'm almost 65 and have several active projects to (hopefully) keep me going for a while. The POC is one of them, my large-scale locomotive is another. Between the two of them, I should have plenty to do as I start to scale back on income-producing work. I'm a bit ahead of schedule on the scaling back, thanks to having been attacked by Pac-Man.

[dclxvi]

I have updated the 65C816 datasheet errata page on the wiki:

http://6502org.wikidot.com/errata-datasheets-w65c816s

While I was at it, I created a 65C02 datasheet errata page:

http://6502org.wikidot.com/errata-datasheets-w65c02s

[Nightmaretony]

Hopefully, WDC can be kept appraised of the errata wiki in order to update their data sheets.

[BigDumbDinosaur]

Nightmaretony wrote:

Hopefully, WDC can be kept appraised of the errata wiki in order to update their data sheets.

They have been.