6502.org

Imagine my surprise when I read through this page recently and discovered Janik's system is so similar to my own... except he's further along than me.

I wanted to build something like I used to design years ago, and see if I could still do it - but I'm trying to do lots of it in 74HCT and proper-sized DIP packages, so I can understand what's going on.

At the moment, the design - as yet untested - includes a 6502 cpu card, which can page up to 4MB of further memory; a 2MB memory card; an IDE interface; a PAL or NTSC video output; and an interface card for PC mouse, keyboard, and a real-time clock. The lot are on a backplane and all the cards are half-eurocard (80 by 100mm) so I can use free Eagle... the whole lot should fit in a 120mm cube

I won't go into gory details here (save to note that there are two AVR Mega8 chips doing specialist stuff, for which the software still needs writing) - if people have interest it's explained at http://www.nailed-barnacle.co.uk/pointl ... tless.html

I'd appreciate any comments. I *hope* I haven't done anything too strange

Cheers,

Neil

Hello. That doesn't actually come as much of a surprise. Most of my design is stol... umm.. 'borrowed' from various sources as well along with some stuff that I have not seen being done elsewhere such as the SIMM-interface with refreshing logic and those ye olde 9-pin "Atari"-style joystick ports. Nevertheless, I'm looking forward with intrest as to see your design come to life in actual hardware

Mine needs a GAL-programmer (going to be using GALBlast for that) to remedy couple of timing problems to make it work properly without intermitted garbage on the bus

Hi Janik,

Is there anywhere yet where your design is visible? I didn't see it on your thread, but I'm good at looking at things and not seing them

I've deliberately avoided GALs and PALs and taken a very old-fashioned approach to stuff - even to the extent of using only a 6502 rather than the later variants or a sixteen bit thingy - so for example my IDE interface uses six chips plus decoding.

<hurriedly disappears for a count>

Overall system proposal:

CPU card: 6502, 32k ram, 32k rom, address decoders, 6850 UART and ram page latch - nine chips

Backplane for five cards inc. CPU - three chips

2MB static memory card - five chips

IDE and RS232 card - nine chips

Bitmapped 512*275 mono video card - ten chips

PS-2 keyboard, mouse, and real-time clock - nine chips

So a total of forty-five chips - I'm sure this could be done in a single thing with a million legs but where's the fun in that?

I've used two AVR Mega-8 processors. Both are arguably more powerful than the 6502 but what the hell... one's generating video ram addresses, system clock, and video sync, latch, and blanking pulses, and the other sorts out the clock, mouse, and keyboard details.

Cheers,

Neil

Unfortunately, as of yet, no. I've deliberately avoided posting schematics at this point because of the problems with the design. However, once those get sorted, they will be made available along with the firmware, some pictures, all of the datasheets and whatnots.

My current chip count is 16 for the mainboard and 4 for the 65c816 CPU module or 1 for the 65c02 CPU module so all in all, 20 tops. However, seeing how I'm having to replace much of the discrete TTL logic chips with GAL chips, this will get down hopefully to 11 or 12 for the mainboard.

Onboard video would be great, but I do not have the PCB real-estate for that. My route for that will most probably be an separate video-card hanging off from the expansion-port or maybe a ISA-adapter so I could make use of the cheap ISA-cards out there. We shall see.

Heh. Fair enough. I reckon if I post the designs, someone might spot something really obvious that I missed
D'you know, I never even thought of that mind you, they were a pig to program efficiently in x86 machine code; on my 8-bit system it could take forever. I'm not sure just how much I can do with this, for there's obviously no hardware acceleration

Neil

It has been done my Mr. Lee Davidson here on 6502.org when he interfaced a ISA slot into his Vic20 to use a 3Com NIC. Link

Impressive - I hadn't seen that. Though I meant it might be difficult to throw enough data around to keep a VGA display full - at least mine's restricted to just 11k

Neil (though thinking about it - the VGA does come with a character generator... or at least, a rom full of characters)

The character mode displays are only 2000 bytes in size (80x25 character matrix, 2 bytes per character). The upper 8 bits forms a color attribute byte, and the lower 8-bits forms the character code itself. Make that 4000 bytes if you use an 80x50 display.

VGA displays can also be shoved into a 320x200 display mode, with 1, 4, or 8 bit color depth. Therefore, I think you'll find performance to be roughly comparable to a Commodore 64/128 system running the VIC chip, provided you don't rely too heavily on software sprites. With 8-bits per pixel, though, you're going to be hurting, assuming your clock speed is 4MHz or less.

VGA displays also give the advantage of having an additional 640x480 display mode, also in 1 or 4 bit color depth. This mode ought to be quite workable, provided you don't do full-screen refreshes. Intelligent updates of the screen should result in workable performance.

I'm looking forward to the schematics of this part....

Hrmm...

You do also remember that, since we're doing whacky stuff and that programmable logic is so damn cheap...

It might make sense to just throw another processor on the video controller board. If you want to get really silly the TMS34010 and TMS34020 processors are available in PLCC packaging which can be put in a wirewrap socket. Alternatively a second 6502/65816 or yet another AVR would be nice.

Taking in the earlier comments, I'm currently considering the option of using a Mega32 as a video co-processor

I'm not too happy about the VGA approach; the cards I found were all sixteen bit cards, and all were too big to fit on my half-eurocard cube spec, and I couldn't get good details about what happens at slow clock rates.

Plus, where's the fun in someone else's design?

So I started thinking about using an M32 as the co-proc: it has enough legs to talk to an external 16k memory for 512*256 pixels, and with a clock at 16M I *think* I can get it to generate all the correct timings for a 'nearly-PAL' spec 312/624 line 50Hz signal. There's about one fifth of the processor time easily available for the pixelisation and writing to the ram.

A single HCT574 latches main CPU requests onto an internal databus, and a couple of HCT74 flip-flops latch main CPU requests and ready bits, and an error bit.

There's enough internal eeprom for a couple of sized sets of font data.

The theory is, rather than hold the data in the chip and build pixels on the fly, I use 20% of the time - field blanking, effectively - to render the data onto the ram, and the active field period to address the ram and load an HCT166 PISO to get the data out.

The bad news is that I can't - directly - use the four interrupts per line with lots of sleeping that I've used before. I still need to think about this.

The interface will be dead simple; read an IO address till the ready bit clears, write a command, and if you care, check for an error. I may include another 574 to latch a response from the coproc if it's required, but it would only have seven bits, I think

Something along the lines of:

00 - reset video and clear screen
01 - move to xxxxyy
02 - write text at current position
03 - line to xxxxyy
04 - set line function xx = xor, black, white

... you get the idea.

Neil (and it's only six or seven chips, so it fits on the half-eurocard...)

Neil,

Check out my ATM8 text video generator code, as it does exactly what you have described. I also used a latch for host data xfer, 74hc74 for handshake, and 74165 for serial shifting.

I use two interrupts, one happens just in time to put the machine to sleep right before the second one starts a new line. This allows for more processing time. You should be able to adapt it to your design.

Daryl

http://users.softcom.net/darylr/io/vid3.html

I was plotting last night and I think I can one-up you, so to speak.

Now, my design is LCD-centric... mostly in that I want to drive the earthLCD el-cheapo 640x480 monochrome LCD... and would probably end up working best on a 65816 instead of a 6502...

I *think* that there's just barely enough pins on an ATmega32 for this, but I haven't actually drawn the schematic out and figured out the details and if there are any nasty things that are going to make it impossible.

But I'm pretty sure that you can make, without too many extra chips, a video controller that uses the AVR to accelerate common operations, but also have it memory-mapped, so the processor can write to it. This way, you can just copy a picture onto video memory from the main processor, instead of interacting with the AVR to do it all, but you can also use the AVR as a character generator and blitter. You shouldn't need external ROM for the character set; just store it in the AVR's flash.

There needs to be a little bit of contention logic, either halting the processor asynchronously or using a latch and then requiring the processor to check if it's done, to make sure that it doesn't interfere with the refresh... and then some tri-state buffers and latches to get the signals routed around properly. So it's going to be more complicated than Daryl's lovely bit of minimalist engineering. Where, I might add, you could take off the 8-bit parallel port and use either the USART or the SPI interfaces and use it in all kinds of projects.

I, obviously, worked this out minimally last night and there may be bugs and problems. Most specifically, I have a bad feeling that I'm going to need one more pin than is available on the ATMega32.

Daryl,

I've already sneaked a peek at your video generator - but if I recall it correctly, you generate characters only? With the memory available within the M8?

I'm trying to be able to do this with external memory, so I can do a fully bit-mapped system. Your double interrupt system is similar to what I've come up with; a main interrupt every 64uS at the start of each line sync; but for accurate timing the cpu has to be asleep then, so I sleep either at the end of active line when I'm displaying video on on a timer at 63uS or so on other lines.

Wirehead - you do realise that chip designers spend fortunes on simulations to ensure that there's exactly one leg too few for all conceivable applications? I mean, I'm a big fan of Atmel, but why on earth didn't they spend the tiny amount of extra silicon necessary to be able to switch e.g. the serial ports, the toggle timer outputs, and the interrupt inputs?

Neil