Fascinating stuff, but I hold the idea that with hardware as with software: avoid the tricksy stuff that makes it hard to understand/debug. Plus, I'll never be Woz...

Neil

I can't judge the situation they were in at that time, but from today's point of view, inmy humble opinion, they've hardware-optimized themselves into a corner were difficult to get out of.

E.g. video: the PET was easily able to replace the TTL mess with a standard 6545/6845 CRTC solution.
E.g. disk drives: the PET could use any kind of disk drive provided it used the IEEE488 protocol. So disk capacity could easily (not cheaply I admit) be increased. And the disk format stored even more data per disk from the beginning.

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

Both did an admirable job, as did the TRS-80 Model 1 ... the Apple was just really far "out there" (for the time), with 16-color lo-res and 6-color hi-res. I don't have comparative chip counts, but I suspect that I can correctly guess the answer.

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

The Apple ]['s video, magnetic storage and sound didn't age gracefully, but the same can be said for many things, including yours truly.

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

I'm doing my best to age disgracefully...

Neil

Anyway, disgraceful or not, here's a field generator for svga (600 vertical pixels, another 28 lines of blanking and vsync). There are a couple of inverters not required in a TTL interpretation, and one missing. I also make the dreadful solecism of moving the field sync one line forwards: it starts on line 600 for four lines instead of line 601, but it simplifies the logic. I'm working on the basis that the reason for the back porch is to allow an analogue monitor time to get the beam back to the top of the screen; the front porch is largely irrelevant.

The counter doesn't need to be synchronous; I think one-and-a-half 393s will do here, using the lots-of-adders approach to generate the contiguous memory addressing.

We'll see if it works when/if I bolt it together... now to look at the line timing. I suspect a similar approach.

Neil

edit: Looking at it, those two inverter-nand combinations could each be replaced by half a 139, saving a chip. Depends if I need inverters and nands elsewhere.
edit 2: or I could use a 238 instead of the 138, with positive outputs.

And to go with it, a line sync and blanking generator on the same principles. Surprisingly few chips; less than I expected. There's sundry other bits, dot clock divider and piso etc to do. Again, I've moved the timings slightly to simplify decoding; the sync pulse is the right length and in approximately the right place in the blanking, which is a shade longer because I'm using a slightly narrower image (image size is 384 * 300 - should be 400 * 300).

Neil

Here's an actual circuit diagram of the work so far. I think some breadboard testing is in order if I have the bits to hand... this starts with a 20MHz dot clock to generate a 2.5MHz ph0 and character clock. It generates the read address for the video ram in the range 0xc000-0xf840; currently connected by highish resistors rather than any formal multiplexor.

Initial plan is to use BE to turn off the 65c02 bus and controls during ph0 low, which works fine for a simple system, but not if there's a 65c22 in the system. So maybe it needs to grab the video to the PISO half way through ph0 low and then release it. I haven't done that bit yet; still thinking about it.

But this is about a third of the final system: I want to include an external processor acting as a DMA controller so there's going to be some interesting bus contention going on

Neil

These days I'd generally recommend not to share video memory with the main processor memory, but I've done it both ways. The last one I did with shared memory was this one (https://github.com/gfoot/compvideo6502), which I was very happy with at the time, it fixed a lot of problems from my earlier designs.

For this I used bus transceivers rather than BE. In fact I think it was an NMOS 6502. The bus transceivers only isolate the memory buses, so address decoding, 6522, etc can proceed as normal even when PHI2 is low. The SR captures a byte of data from RAM towards the end of phase 1 just before the memory bus is given back to the CPU, then shifts out the data over the course of the clock cycle. I think the pixel clock was 16MHz.

I think that sburrow's Acolyte system uses a similar arrangement to what you're proposing, with BE - I may be misremembering though. It might be worth taking a look at that. But I avoid BE for this sort of thing.

I agree to using buffers and not BE. As gfoot said that makes IO much easier.

Here are some examples of memory sharing for video: http://www.6502.org/users/andre/petindex/crtc.html

The 'big' Commodore floppies even had two 6502 (resp. 6504) running on opposite phases of the clock sharing some memory area. With the 6502/65c02 this even worked with sharing the data bus between the CPUs and only buffering the address lines: http://www.6502.org/users/andre/petinde ... index.html

Hope that helps
André

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

To be honest - swings and roundabouts at the moment. I'm also considering using CBT2345 bus isolators between the video address and the processor address, in which case it's goodbye to all those 47k resistors.

The fun will start with the DMA because that also has to share the addressing and data, but while DMA is happening the processor will be stopped but the video has to keep running. In normal use the DMA will be to and from the top of the video ram at 0xfd40 and 0xfeff but will be able to write anywhere in the memory space, so for initialisation it will write not only the boot loader/monitor and reset vectors but the font table and even a splash screen directly into video memory.

Neil

I'm still kicking around ideas for how to interface the STM part to manage DMA... I need it both for the original system load (easy, just hold the processor in reset and with the busses disabled, per the Romless) and to read and write smallish blocks of memory at effectively random but infrequent times: UART in both directions, 1/2k sectors of data to and from disk, and whatever I think up later (I suppose one possibility is for the STM to be a video coprocessor reading a command list and writing direct to video ram?).

Because the STM will be running asynchronously to the 6502 (and somewhat faster: 32MHz vs 2.5MHz) but the video must run uninterrupted through the active image times, I suspect the easy way to do the DMA might be to wait until field blanking - 28 lines, about 750us - and if data needs to move, stop the processor (RDY), disable its databus etc (BE), drive the data transfer and then re-enable the processor before we to the next active line zero. The video addressing is being driven through resistors anyway so it won't care who else is driving the bus.

Make any sort of sense?

Neil

It sounds good, I guess the disadvantage is having long periods with the CPU completely paused, so long interrupt response times during DMA, and also having a potentially long wait for the start of a DMA operation, e.g. 10ms or more. It might not matter with the microcontroller, but for urgent DMA caused by something time-critical like a floppy disc, it wouldn't be acceptable. Filling an audio output buffer is another similar case, which might be OK if the audio latency of a large enough buffer is acceptable. I'm not sure whether you plan to use DMA for anything like that.

I guess the other two alternatives that you've probably considered are using the horizontal blanking period instead which would reduce a lot of these worst-case delays, or deciding per-CPU-cycle whether it's going to be a CPU cycle or a DMA cycle, which is an interesting priority/scheduling problem but much more complex I imagine!

The worst case paused is @750us, which is definitely noticeable on audio, but I'm not including any of that so that's not a problem (unless I offload it to the STM). I considered using the horizontal blanking, but I'm not sure how much I can get done in 6.4uS - that's only a couple of hundred clocks for the STM, in which it has first to _find_ the blank.

If I could guarantee always accessing the data when the 6502 isn't - ph2 low - then that would be ideal; the video is already doing that. But I think that would need additional hardware between the bus and the STM to hold data and wait until it's time to write it (and more to read data).

There is that potential wait of up to 600 lines - 16ms for a data transfer but I think most of the transfers will be either bulk data to/from a microSD, which can wait, or keyboard characters - which might fit into a line sync anyway.

First make it work, then make it good...

Neil

To stop the 65c02 I believe I need only ensure that ph0 is stopped low: viewtopic.php?t=939
This is easily done with a d-type and an AND gate.

The clock output stops and starts in the correct phase irrespective of the phase in which the switch occurs, so the STM needs to pull the clock enable low when it needs the bus, pull BE down either after monitoring the clock or just waiting one clock period - 400ns - and it's just fighting the resistors from the video ram address generator. If it does it during blanking, then the VRAG doesn't care; the data isn't displayed.

Neil