6502 Forth with hardware accelerator

[dclxvi]

Dr Jefyll wrote:

However, I find the '816 data sheet somewhat ambiguous as to which address modes accommodate Bank crossings and which merely wrap around in the low-order 16 bits.

• The program counter wraps at bank boundaries
• rel and rl (branches) wrap at bank boundaries
• xyc (MVN and MVP) wraps at bank boundaries
• (abs,X) wraps at bank K
• (abs) and [abs] (JMP and JMP/JML) wrap at bank 0
• The direct page and stack wrap at bank 0

Pretty much everything else can cross bank boundaries. This means, for example, that the 12,S part of (12,S),Y wraps at bank 0, but the ,Y part can cross a bank boundary.

[GARTHWILSON]

Quote:

it becomes uncomfortably apparent that the '816 lacks the Long Pre-Indexed-X Indirect mode you require. The workaround is a two-step operation that begins by updating the Data Bank Register -- more or less as KK does!

Since I developed my '816 Forth on an '802 which does not have access to anything beyond bank 0 (as it's an '816 made to go into a 6502 socket), I have not yet done the material for accessing 24-bit addresses. But I might at least sometimes just use a few DP variables to form those long addresses for the indirects instead of modifying the bank registers' contents. I'll have to see what works best; but I basically want it to look like a continuous 16MB space with no bank boundaries. I realize bank boundaries and bank registers have their advantages sometimes, but my use will be quite different from the typical use of the Apple IIgs for example. Of course memory moves using MVN and MVP do involve bank numbers. I plan to keep all actual Forth executable code in bank 0, which is a lot of space for Forth if the largest arrays & tables, and files, etc. can go outside bank 0. I've started getting parts to make my '816 computer.

Quote:

(Because of this issue, if I were writing an '816 Forth I would lean heavily toward using SP, not X, as the P-Stack pointer.

And put the return stack where?

[Dr Jefyll]

Quote:

And put the return stack where?

Well, I haven't seriously started coding. In fact I've never written anything for the '816. But I'd plan to keep the Return Stack Pointer in Direct Page and load it into X when required. The Forth IP would live in Y, and FIG style double-indirect NEXT would be as follows:

Code: Select all

 NEXT:     LDX  0,Y    ;fetch via IP
           INY         ;bump IP
           INY         ;
           JMP (0,X)   ;X is Forth's "W"

This is fast -- about 14 cycles! The cost of keeping the R-Stack Pointer off-chip seems worthwhile.

FWIW, the Forth I'd build is a 16/32-bit hybrid -- generally 32-bit but with exceptions regarding code. (Stack items occupy 32 bits, and @ and ! use Long addresses and access 32-bit data. But the Dictionary resides within 64K, and tokens are 16 bit.) In fact I still use my old 80286/386 Forth that's written this way. I wanted a data space bigger than 64K, and didn't want to be stumbling over FAR@ FAR! FARC@ FARC! etc etc (as I'd done with the KimKlone). In fact I was fed up with mixed precision in general, which I was doing a lot of due to the Far addresses being tossed around. It reached the point where 2SWAP 2DROP 2OVER and all the rest began to seem like tools for generating for errors and unreadable code.

I wanted something easier, and the solution was to simply make 32 bits the default. Yes, a 16-bit CPU has to work harder to make this happen, but the performance hit isn't as severe as you might suppose (given that you'll always have substantial overhead for NEXT BRANCH NEST UNNEST and so on -- which remains almost unchanged). If there's any interest we could start a new Topic about 32-bit Forth running on 16-bit hardware. In fact an '816 version could reuse a lot of the high-level coding (mainly compiler alterations) I did for my 80286/386 Forth.

[GARTHWILSON]

Bruce's idea of using the 16-bit stack pointer as IP so NEXT is simply RTS practically took my breath away a couple of years ago when he proposed it, but without being able to use the hardware stack (the one that's in page 1 on the '02), you can't practically have interrupts. Subroutines using the hardware stack are almost a non-issue, since non-subroutine-threaded Forth has almost no subroutines and it wouldn't be hard to do a work-around for the seldom times you do have a subroutine.

We had a very extensive (9 pages!!) discussion on an all-32-bit 6502 at viewtopic.php?t=1419 . Basically a byte would be 32 bits, and there are no shorter loads and stores than that. Reading 32 bits happens in a single clock. With a 32-bit address bus, data bus, and registers, basically the whole 4GB space is in page 0 (eliminating the ABS and LONG addressing modes), and the stack pointer also spans the whole range. (Although I wrote "GB", remember that they're 32-bit bytes, so it would be as much memory as 16GB in the terms we're used to, although the usage won't be as efficient.)

[Dr Jefyll]

Sounds like that discussion includes some of the same goals as mine; I'll check it out. Ummmm... It also sounds like you're designing a new CPU! For now I'll be content with my Virtual Machine that lets me run 32-bit Forth on an embedded 80186, a PC (and perhaps someday an Apple IIGS or '816 SBC)!
[Edit: clarify VM remark]

[Dr Jefyll]

In another thread I mentioned 'C02 undefined instructions, and was speculating on whether the Rockwell and WDC chips treat these "illegal" opcodes the same way. After installing a WDC CPU in the KimKlone I'm convinced they do.

I admit it was a thrill to see this comparatively ancient computer boot up with an updated CPU, and I did a little photo session that day -- a portrait, as it were, of the machine that occupied so much of my time, both in its creation and in the following years as a tool used day-to-day (in the same manner as Garth's Workbench Computer). Today for some Friday-afternoon frivolity I decided to share a few of those shots. (Older pix can be seen here.)

The KK included quite a lot of stuff that was rarely or never used, and the keypad and LED display (above) are definitely in that category. But, on the plus side, I notice the LED display photographs quite nicely! In this shot, the machine monitor is running and the address and contents of a zero-page location are displayed. (KK uses six-digit addresses).

Pin 1 of the WDC cpu (VPB) is bent outward so as not to engage the socket. The removable daughterboard at the top left is an RC oscillator, adjustable via trimpot for test purposes. Its output (presently 80 MHz) gets divided down to supply video and CPU clocks.

Here's the video display, showing mostly just power-up garbage in RAM. The video format is extremely flexible, but defaults to 16 kilohertz scanning suitable for re-purposed NTSC televisions. That limits us to 32 characters per line -- which I found to be adequate or even preferable when the material viewed is Forth source code!

This last shot is just silliness, hamming it up for the camera. After the Fig-Forth greeting and OK prompt, you can see I've entered a text string in English -- not Forth.

Playing coy, perhaps, KK responds with message code zero, indicating it hasn't recognized the first word, "say." (Then I hit CR a bunch of times to bring the dialog to center screen.)

cheers,
Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

...I admit it was a thrill to see this comparatively ancient computer boot up with an updated CPU, and I did a little photo session that day...

A whole lot of chips and no vile-smelling smoke. Now you should be able to really crank up the clock.