It's going to be a nice weekend out here on the homestead, so unless I injure myself with power tools, there won't be much time to mess with Vulcan-74 for a few days.
I did layout the GPU based on the messy diagram above, and might have enough time to test the XY counters tonight when the skeeters come out.


If my plan works, then this will be the GPU.


Who's who in the Solderless Zoo.

From the description above, this is how the GPU (should) work...

A 10 nanosecond bank of 1024K of memory (Graphics Memory) runs on its own isolated 20 bit address bus, fired by a series of 163 counters clocked at 20Mhz.
This is contiguous memory holding the "sprite data". The CPU can preset set the 163s with 20 bits of "Source Address".
The GMEM is clocked through 3 stages, with a series of 574s that keep propagation below 40ns, and allow switching to the dual buffer Video Memory.
As pixel data is pumped out of the GMEM, it is qualified with a known value set in the 688 comparator by the CPU, which is called "Alpha Color".
Any data NOT equaling Alpha, is sent to the VMEM data port, registered in sequence with the address and WE, controlled by the Alpha logic.
Data equaling the Alpha Value is considered "transparent", and is not drawn. This is how the GPU handles automatic transparent pixels at 20MHz.

On the "Destination" side of the logic, we have a split set of chained 163 counters running the X and Y address counters to the VMEM back buffer.
The CPU presets these values; Destination-X1 and X2, Destination Y1 and Y2. This tells the GPU where on the screen to draw the sprite block.
As you can see, sprites are not limited in any way, and can be as small as a single pixel, or as large as 512x512 due to the 9 bit XY addressing.
A few 688s control the resetting and wrapping of XY counters, and then trigger a "Ready" signal at the end of a sprite transfer.

This next stage in design will be more interesting for me since everything from here is untested.
Having done VGA designs in the past, the video section was not much of a challenge.
No doubt, there will be revisions, so wiring will be messy as I prototype the GPU!

Will try to make a few more posts this weekend.

Cheers,
Radical Brad

Well, the weekend passed on by, and it only left me with about 30 minutes of time to work on the board.
Managed to connect VCC and GND wires on the top half of new ICs, so at least something was done!

I only connected chips from the 574 Address Switch row and up, as these are the destination counters.
While I was banging nails into trusses (and my thumb), I figured that testing only the XY counters would make debugging easier.

With only the XY (destination) counters working, I would at least be able to draw blank blocks to the screen, simulating sprites.
With no source counter running, there will be no real pixels, but by tying the GMEM data-path to some value, I can move colored blank blocks.

Once I have variable sized blocks flying around the screen at 20 million pixels per second, I will then add the source counter section.

If anything is going to be trouble, it will probably be the alpha pixel control circuit, as it has a 40ns reaction time, leaving 10ns setup time for the next 574 stage.
This is most likely no issue at all since I am working with worst case timings form the datasheets, but it is now my slowest path of any signal.

40 nanoseconds... damn, I could go make fresh coffee and get back before the rising edge, man!

As far as testing the GPU as it is being built, I will be relying on an AVR1284, as it offers 128K of program memory, and 32 IO lines.
With that much program memory, I can stuff the video memory with a full screen bitmap, and make sure there are no missing pixels.
With 32 general IO pins, I can simulate the control of the GPU, which will be the job of the 6502 IO logic later on.

Ok, talk at y'all later!

Brad

Better late than never...



Cheers!
Radical Brad

You could have typed "35 years from now"... instead of "In 35 years"... You could have hit Return and it would have accepted it without syntax error

(Sorry couldn't resist)

===Jac

That reminds me of the old Jim Butterfield trick that utilized the behavior of the BASIC interpreter in Commodore machines to amuse the audience:

Code:

10 IF TANDY THEN PRINT"Ugh!"

When the above code fragment was run it would produce a ?SYNTAX ERROR IN 10 retort, ostensibly because TANDY (i.e., Radio Shack for those who aren't familiar with the company's history) was "mentioned" in the program. It always got a laugh out of everyone.

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

If T and Y aren't initialized to anything, they will be 0 at run-time, and the expression T AND Y will evaluate to 0 as well, causing no action taken. I don't see it as a syntax error, unless I'm missing something.

Mike B.

According to the emulator at
http://www.thomasskibo.com/6502/pet2001/
it's as BDD says. I suppose the PET Basic demands spaces. (Edit: makes sense, really, as the T introduces... I was going to say variable name starting with T but in fact it's TAN the function)

As Ed surmised, the problem has to do with the TAN in TANDY.

Commodore BASIC (which is essentially Micro-Soft BASIC) wasn't at all fussy about whitespace during program entry, which made gibberish such as FORT=1TO1000 (FOR T = 1 TO 1000) completely acceptable. The reason is that the tokenizer would do character-by-character pattern matches on the input buffer during code entry looking for supported BASIC verbs and functions, such FOR and TO. As a result, BASIC had no trouble figuring out what FORT=1TO1000 meant, as it would tokenize FOR and TO, replacing them in the program text with one byte values (with bit 7 set to indicate that the byte was a token) that could not be confused with the variable T and the literal numbers 1 and 1000.

Trouble arose only if a character string looked like a function or verb when it was actually supposed to be an expression. Hence the programmer might think that TANDY is the expression T AND Y, but the interpreter's tokenizer would see TAN, followed by DY, and would tokenize TAN (a BASIC keyword) but leave DY undisturbed. During run-time, the interpreter expects TAN (and other functions of its type) to be followed by a parentheses-enclosed numeric expression, e.g., TAN(DY). In this case, the interpreter would encounter the token for TAN and upon executing the corresponding code, would evaluate for an opening parentheses. Instead, it would read D from program text and raise a syntax error.

There was some advantage to being able to omit whitespace in a program. The program would be smaller, hence would load from mass storage more quickly, a significant consideration back in the days of painfully slow tape cassettes. The program would run faster because BASIC's CHRGET, which is responsible for reading program text and determining if the byte returned is a token or something else, would not be reading and discarding unnecessary whitespace.

Most modern forms of BASIC (but not Microsoft's QBASIC) not only tokenize BASIC keywords they also perform a similar process on variables, which usually results in unnecessary whitespace being discarded during program entry. Business BASIC implementations go even farther and generate an internal "symbol table" that is arrange for rapid look-up of variables, branch targets and subroutines. Instead of searching the program text during run-time for, say, the address of a subroutine, as is done in Microsoft BASIC, the interpreter scans the symbol table, using a binary search to improve speed. A similar process is used to find variables and access their content. The result is that the average business BASIC runs quite a bit faster than normal interpreted BASIC.

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

You prompt a thought - I'm sure I've seen a Basic where some of the function names have tokens which include the opening parenthesis. Not only does that save a byte, but it avoids the problem of matching on a variable name.

I've seen implementation of interpreters that normally do not even need the symbol table at run time. The byte code contains only indices to the symbol table, which then points to the data area. E.g. the APL interpreter of the IBM5120 was such a case. As APL saves workspaces and not only programs it was possible to overwrite the names in the symbol table (there was a backdoor that allowed peek and pokes bytes everywhere) with the same name for every variable. So the program in the workspace still worked, unless you had code that constructed the variable to use, but reading it was rather difficult and you could not make any changes.

I've not run into that with any of the BASICs with which I'm familiar. The environment in which I do most of my business application development is Thoroughbred Dictionary-IV, whose core is a business BASIC interpreter. I can tell you that when the programmer enters a line of text that line is not only tokenized it is evaluated for syntax and will not be "compiled" to T-code (what Thoroughbred calls their crunched program text) if syntax is a problem—a syntax error will be immediately reported. In order for that to happen, parentheses evaluation would have to occur during the tokenizing process. So I suspect there is quite a bit of optimization taking place during program entry.

Thoroughbred's BASIC engine has functions that can convert a character string into program text on the fly, which not only means that source code can be created in a text editor, it means a program can be self-modifying, a trick I've used in some report generators. Hence it is clear that the part of the engine that accepts code entry has to be doing a lot of work on the text prior to it becoming executable code. It all works very well, as these programs are very fast, even on older hardware. My very first UNIX box was a 16 MHz 80386 unit (with a math coprocessor) and had Thoroughbred's BASIC 8.0 engine. I was quite impressed with the general performance.


Business BASICs are designed for program chaining, which means the symbol table has to be available so variables created in one program are available to the next one. There are actually two such symbol tables, one which is program-specific (subroutine addresses, etc.) and the other for the variables. Program chaining was a necessity on the earlier minis because of limited amounts of memory. Chaining continues to be used to make it easier to modularize applications.

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

I searched. Most likely it was BBC Basic. Very odd set of functions have their open paren in the token - not all of them, and not TAN.
"The tokens for TAB, INSTR, POINT, LEFT$, MID$, RIGHT$ and STRING$ include the opening bracket"

I apologize for not testing the statement on an actual emulator before running my mouth. Ed, for an interpreter design of my own, I would certainly include an open paren in every token that unambiguously required one (including TAN), but that ship almost certainly sailed many years ago.


Mike B.

[Edit: I just realized that we (especially I and BDD) are contributing heavily to thread drift here. I apologize to Oneironaut, and will drastically trim this post to avoid distracting anyone from his great topic here, if he asks me to do so.
]
[Edit #2: I did it without being asked ... it just seemed the polite thing to do.
]

I can only think of two reasons why a Basic might tokenise some but not all opening parens: it was a late idea implemented only for later additions; to save a few bytes the token table was raided for spare opening parens.

Yes, pity about the thread drift. At least it's somewhat on topic for 6502... but it is in the Hardware section.

Not much to report yet, but did manage to get some more wiring done.


Power and Clock Lines.

Connected all of the VCC and GND wires to the new chips, and ran the clock lines to all of the 574 registers (blue wires).
Usually, I use blue wires for clock and data, brown wires for control lines, and white for addressing lines.


An ATmega-1284 to be used for graphics tests.

Before I connect the 6502, I need to verify my design. I will be using an ATMega-1284 to test the graphics and GPU.
Since I can code AVR assembly better than I can chew bubblegum, this is the most logical way to debug the hardware.
The AVR will hurl pixles to the back buffer and then swap the memories so that the switching system can be verified.


GPU address switching wiring completed.

Much like the dual switched bus of the Video System, the GPU must also have its own switchable dedicated bus.
The GPU to Video side of the bus is a dual 18 bit address bus and dual 8 bit data bus. There are also 2 control lines.. OE and WE.

My next test will be to bolt the AVR to the input side of the GPU switch and simulate pixel data coming from the dedicated Graphics Memory.
Graphics Memory is a 1024K serial stream from a dedicated bus only available to the GPU. Data is sent at 20MHz.

Oddly enough, I have not even tested the video system besides seeing random pixels, but I can't image why it wont work perfectly.
This circuit is a direct copy of the original mess, so it should be 100% functional.

The first test will be a 400x300 image with 256 colors. A single pixel border will be drawn to ensure that no pixels are fat, skinny, or missing.
The border pixels are the most difficult part of a video system, and of all things, this has been the most challenging thing to perfect.

I will be wiring up the AVR for testing tomorrow, and will post again soon!

Cheers,
Radical Brad