Circumstances in my life will not let me solder and/or print boards at the moment. So instead I just design schematics, for now.

As I'm always looking to make things bigger and better, sometimes it's funny to try and go in reverse. Presenting an updated version of the "Ultra-Minimal 6502" build. I'm calling this one my AcolyteMini, because it's based off of my previous designs (here viewtopic.php?f=4&t=7096).

65C02 running at only 1.57 MHz. 16KB General Purpose RAM, 16KB Video RAM, 16KB Unused Expansion, and 16KB ROM. This design only uses 12 chips! And it is better than the previous model because it does not require 'racing the beam'. You can program and code however you like, without worrying about the video signal.

So, why so slow? The main reason was because I can now make the Video RAM only 16KB, producing 320x240 monochrome. This is (in my opinion) barely usable, but usable none-the-less. Also, because it is so slow, I can alter my VGA latching schemes just a tiny bit, given that I have so much free time between clock cycles. This simplifies the glue logic a LOT, leaving me with more free gates than I expected. So much so that I've actually spend nearly a week trying very hard to make the memory map better than what you currently see. Oh well.

Video signals still come from the ROM, but I'm also sharing the ROM with program code. I have 3 extra signals I could use, but I don't see a need for them at the moment. Having the video signals in ROM allows me to not 'race the beam'.

To cut down on chips, I decided to use the BE pin on the 6502. And, because the clock speed is so slow, it doesn't seem that it will work any worse than 3x '245s instead. Anything to reduce chip count!

And then, PS/2 Keyboard input... through /NMI and /SO! I've done a lot of research (hopefully enough to make it work) on this SOB line. It is negative edge triggered only, so between each clock pulse from the keyboard I bring it back high through the OR-wired diode logic. Attached is my demo code for the keyboard interrupt. The problem here was that the computer is so slow (for the video signal) that it makes it more difficult to program for the keyboard. I had exactly 94 cycles between each data signal, and I managed to get it down to less than that. This particular code makes nested interrupts. Thankfully the stack is 256 bytes, because I'm using 60 of them just on this keyboard interrupt sequence!

Because I have the /IRQ line open, and 16KB of unused space in the memory map, this theoretically could have an expansion using a VIA, or perhaps just more ROM.

Whelp, there we go. A *easy to use* 6502 build with VGA in only 12 chips. That's a win!

Thanks everyone.

Chad

Interesting! It's only running in bitmap "mode" if you can say so, right? A big complication in character-based graphics is to have to either buffer the character data (that is then index into a character generator memory) for a number of pixel lines (the VIC-II does this, in the bad lines), or read the character repeatedly, and for this have to reset the address counter to the beginning of the screen (as the 6545 and e.g. the PET does it)

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

Busy-waiting inside an NMI handler and intentionally nesting them twelve deep is an "interesting" strategy. If it serves its purpose adequately then kudos to you for your outside-the-box thinking.

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

There was a (proposed?) trick for high density disk interface on the Beeb, which involves nesting interrupts so densley that the RTI is never reached...
https://beebwiki.mdfs.net/High_density_ ... isc_access