Still working on this! I've figured out that my scheme for generating read/write pulses is flawed. I had ANDed my 3.5MHz (Phi2) and !7MHz clocks to produce a shortened pulse that doesn't coincide with Phi2 going low. Trouble is, if the 7MHz clock is at an earlier phase than expected this produces a second little "blip" at the end of Phi2-high. This has resulted in errors ranging from the blitter drawing an extra pixel on its first line, to the gamepad adapter triggering its selection bit unpredictably. The new approach I'm gonna try is using a 74HC74 flip flop to shorten the signal in a similar way to the AND gate, but in a way that won't add a "blip" when !7MHz goes high before Phi2 goes low.

Also I realized that I'm hanging too many things off my main clock signals without buffers, so I made a little adapter shim that goes between the motherboard and one of its modules to buffer and divide the clocks in isolation from the other users of the clock on the motherboard.

Finally, I've written an implementation of the famous Bad Apple demo that leverages the blitter to quickly draw the run-length encoded video! This also utilizes the 2MB flash cartridge I posted about in another thread, since I couldn't exactly fit the video data into my original 8KB cartridges. The demo also uses the new Audio Coprocessor module to play back essentially a converted MIDI in sync with the animation. In the process of getting the demo to look somewhat nice I managed to hammer out a few bugs in the blitter and video signal boards. As a result I'm fairly optimistic about achieving the final "game console form factor" version this year.

A recording of the new demo is at https://youtu.be/hyqNS5GmLEY

Whoa -- terrific work! I'm referring to the project as well as the video. And your web page for this project is also very nicely done.

As for the clocking question, am I right in assuming your 7 MHz clock is divided by 2 to produce the 3.5 Mhz which the CPU uses? And (correct me if I'm wrong) you wanna generate a similar 3.5 Mhz signal, but one that has only 25% duty cycle -- low for the first 75% then high, or is it vice versa... If you share the circuit you're presently using then we can suggest alternatives if you're interested.

-- Jeff

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

That'd be great! I actually have a 28.somethingMHz oscillator module that gets divided into 14, 7, and 3.5MHz clocks by a 74HC4040. So each clock ticks on the *low-going* transition of the next higher division. Initially I just gated !RWB with Phi2 to generate a write-enable, but later found that cutting it to only the first half gave me more timing leeway on level-sensitive logic.

The schematics attached are for the motherboard, with two of the images being clipped to the relevant clocking and gating sections to read it easier.

EDIT: Also all the 74xx chips on this board are actually 74HC, the ones that say S or LS are because the Eagle builtin library didn't have HC and I'm a little bit lazy.

Alright, I have a few questions and suggestions. I'll begin with one that's fairly minor. Would it be acceptable to replace the oscillator with one that's half the frequency -- IOW, go from 28 Mhz (approx) to 14 MHz? That'd mean your CLK14 signal would be taken from the oscillator, not from one of the 'HC4040 counter outputs.

What is driven by CLK14? It would end up with the same duty cycle as the osc. -- ie, roughly 50:50 but not necessarily exactly 50:50. Do you know if that would matter? As you may've guessed, I'd like to replace the 'HC4040 divider circuit. Some sort of synchronous divider will be more appropriate than using a 4040 ripple counter, whose outputs don't change in unison. And, more options become available if the new divider doesn't have to supply CVLK14, only CLK7 and CLK3.5.

Okay, there are various ways of shortening write-enable so it only occupies the first half of the Phi2-high period. But shortening write-enable may not be necessary if you can instead find a way to shift its phase somewhat so the trailing edge happens a tad sooner, relative to CLK3.5 aka Phi2. Here are some options for that:At "A" you could reduce the propagation delay substantially by replacing each AND-plus-Inverter with a NAND. And/or you could use AHC series parts here instead of HC -- this is something you could easily test, as the chips are socketed.

Another way to delay the phase somewhat is to break the circuit at "B" and insert two inverters or a single non-inverting gate such as AND or OR. And (although I didn't show this) it's not only the CPU that'd get the delayed phase; the VIA would, too, and really everything using Clk3.5 except the tinted area at A.

BTW, no matter how you derive the Phi2 sent to the CPU, it's best to have abrupt rise/fall times there. It's far from ideal that you're presently using an HC series device (the 4040) to drive the CPU's Phi2 input... and also driving the VIA Phi2 input and some other stuff!

An AC series device would do a far better job of driving all that, but a few simple caveats apply when using AC. If you prefer to stick with HC -- not really recommended, but you have, after all, gotten things working! -- then I suggest you dedicate one HC output whose only job is to drive the CPU -- nothing else. Probably the VIA could also benefit from this treatment for its Phi2 input. In both cases Phi2 is interpreted with significance attached to rising/falling edges. In contrast, abrupt rise/fall times aren't as important for those logic inputs which are merely level sensitive.

-- Jeff

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

Thanks for the analysis!



The 28Mhz clock actually gets used by the video board for generating colorburst phases, and by the blitter for shortening its own write pulse.
The 14MHz signal is also used by the blitter as its pixel copy clock, and by the audio board to clock its own 6502.
The blitter assumes that an incoming write pulse to its "start" register coincides with the falling edge of its own clock, and lasts for a full 14MHz cycle.

However, it sounds like switching the divider to a synchronous counter would still serve these clocking needs and make these assumptions valid. Replacing it with an AC part also seems like a good idea. Maybe a 74AC163, and pass the oscillator's output through a 74AC04 to maintain the expected phase relationship. This could even be implemented before the next full motherboard respin, if I build it on a board that sits in the 4040's socket.

Nice!

But before watching yours I had first done a quick search for "bad apple demo" on YouTube and seen this amazing Atari 800 version first, which kinda spoilt me as far as music goes. But I'd think with a 14 MHz 6502 dedicated to audio you ought to be able to improve the music a lot on your system, right?

_________________
Curt J. Sampson - github.com/0cjs

Yup. A lot of room for improvement on the software side. So far the main limiting factors I've run into are that multiplication/scaling is slow, and it needs to compute each sample within 1024 cycles to keep up a roughly 13kHz sample rate. A rough scaling approximation for applying ADSR is done in the demo by repeated shift opcodes, though more channels can be added if that step is skipped and the channels play all-or-nothing at a fixed volume.

Still progressing on this, albeit slowly. I had a little substitution board made that lets me seat a 74AC163 in the socket of my 74HC4040 main clock divider. This has immensely improved system stability.

Most of the remaining hardware fixing is in the blitter module, which seems insistent on writing an extra pixel for each row and another little extra pixel in the corner after its done.
It could probably stand a total redesign, being one of the first parts of the system I drew up. I'd like to think I learned a bit more about sequential logic in the roughly two years since.

Meanwhile I've added a WebAssembly build target to my emulator, which was easier than I'd thought it would be.
https://clydeshaffer.com/builds/GameTankEmulator/wasm/
In addition to the demo ROMs in the drop-down menu it can load files from local storage, which will make it easier to trick (er, I mean "invite") my friends to develop for the console.

I love the minimalism of your design. You use one chip where others use 20. I also like your clock fix. Welcome to 74x161 style clock circuits.

I'm not sure why your working implementation of a 6502 audio co-processor gets less response than a similar topic about multi core topology. I hope it is because there is less scope for speculation and not because the concrete application is leisure.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

I've been thinking about the off-by-one blitter problem. I initially thought that it was use of 74x163 synchronous reset rather than 74x161 asynchronous reset. However, you are not using the functionality which differs. Looking closer at the blitter diagram, SYSCLK is ahead of DMACLK which is ahead of _ROWCOMPLETE which is (presumably) ahead of _COPYDONE. I presume the latter two advance on the wrong synchronous clock when asynchronous is more desirable. Regardless, it is a remarkable achievement to implement discrete video and a discrete blitter.

Also, you are quite forward looking with WebAssembly. I thought that I was first to mention it. However, you are fourth and I'm fifth. You also have working software.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

I've redesigned the blitter clocking to generate four distinct clock lines, each running at 14MHz but offset from each other by 25% phase. This would separate clocking the Width counter from clocking the X, Y, and Height counter and fix the off by one error...

Except that the 74HC40103 I use for the Width and Height counters has around 35-40 ns of prop delay from CP to TC and I've overlooked that all this time, being too focused on the access times for the RAM chips. At the rate I'm trying to run it, this ends up being about a half cycle's worth of delay. I'm gonna try to patch the board I have now to run the blitter pixel clock at 7MHz instead of 14MHz, and switch to that if it fixes the issue. Given that a 1MHz pixel clock would be enough to write to every pixel on the screen sixty times per second, I wouldn't be *too* torn up about slowing down this contraption a little.

Well, I had to slow the blitter down to 3.5MHz instead of 7MHz but it is finally drawing the correct number of pixels every time. The delay from the 74HC40103 was just a hair too slow to run at 7MHz, but I might be able to get it working at that speed by delaying a certain clock phase. I'm satisfied with the result enough to call that a "wishlist" item rather than mandatory for moving on towards the "form factor" version. (i.e. the one actually shaped like a game console)

Screenshot attached to show the blitter working its magic for my Tetris clone, drawing the pieces and interface mostly with colored rectangles but also using a font stored in G.RAM to print the score.

I got excited after getting the blitter working, so I sat down and combined the four board designs of the V2 prototype into a surprisingly compact two-board stack. Combined PCB footprint is 7"x6" and hardly an inch and a half high.

The bottom board combines the blitter, address decoding, CPU, input ports, cartridge port, and VIA.
The top board holds the composite video circuit on one side and the audio coprocessor on the other. So I call it the "Signals Board".
The Signals Board has a hole in the middle to accommodate the cartridge, which site on the bottom board for structural stability.

The keyboard switches used for Reset and two extra input buttons have been replaced with headers, to connect to case-mounted switches.
I've also left a footprint open in case I wanted to use a 3.5mm mono jack for the extra input buttons. This would, for instance, support connecting to certain exercise bikes. I think that would be kind of hilarious.

In the corner near the RCA connectors, I put a header that exposes twelve otherwise-unused VIA pins. Besides eventual expansion hardware, this is handy for debugging and profiling

I haven't actually tested out the tweak that would bring the blitter speed back up to 7MHz, but instead included it on the new board with a trio of solder jumpers that would either enact the 7MHz fix or simply route the 3.5MHz version that would still be sufficient for games.

I've also elected on this version to remove the existing linear regulator and instead leave a place to solder in a power module that I'll design later. This could either stick out the back a little, or go underneath the lower board.
Initial testing could be easily done with a bench power supply, or I could just solder in a barrel connector and use a wall wart that already outputs 5V.
The reason I switched from the regulator is mainly that it got very hot, even with a heat sink attached. I'd like to switch to a switched regulator instead, but still have some reading ahead of me to comfortably understand how to use one in a design.

So that I could start designing the case, and also have something to post on my website, I exported the boards to Fusion360 and created a fairly detailed rendering. (After a couple hours' worth tracking down STEP models for certain components!)

That's a very handsome kit! Nicely done.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

_________________
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?