I'm not keen on them either, but I agree the margins are probably quite forgiving. Edit: I see you've just posted again, but I'll finish what I started...

Instead of using a counter, you can make the shift register count by adopting a "sentinel bit" approach. The shift reg can initially be cleared to all zeros, and you can arrange for the Start Bit to always be 1 (it's actually 0, but there's no great inconvenience to inverting all the incoming serial data).

Now you can be certain Qh' of the 595 will go high after exactly 8 clocks, and not before. And I would extend the shift reg by feeding Qh' into one of the two 4-bit shift registers in a 74HC4015. This is an active part, in stock at Digikey in both SMD and TH. Or, its predecessor the low-speed 4015 might suffice.


Now you have four more outputs, and they can dictate specific actions. One of them will go high when it's time for the '595 to copy its internal shift register into its internal output register, and a later 4015 output can clear both shift registers back to all zeros. (On these last two points, be mindful of the timing.)

Half of the 4015 remains available, so I would just ignore 3 of the bits and use it as a flipflop. It should be adequate to store the "I need interrupt service!" flag.

-- Jeff


PS- Daryl (8bit) has a software solution here. But I'm guessing your machine is presently too slow.

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

Dr Jefyll:
I may give your approach a try at a future stage. I had actually thought of inverting the data and using the start bit as a flag to stop counting, but ended up deciding on using chained shift registers. As the hardware is already soldered and working, I'll leave it as is for now. I may be able to reset the registers using the output from the address decoder and latching the output with phi 1, but haven't tried it yet.
I have tested the Keyboard running at 1 MHz and it works fine. At KHz speeds it of course misses data frames, so to use the keyboard I'll have to run at higher clock speeds.

I finally have fixed the IRQ (or so I think) and now seems to work as expected.
It didn't work right because my original design was wrong. I thought that I had tested it appropriately on the Logisim simulation, but seems that I didn't.

When IRQ went low, I was "forcing" a BRK opcode into the Instruction Register on the next instruction to be executed. Not only does BRK have a padding byte that will mess everything up if triggered unexpectedly, but the Program Counter is incremented at the start of each new instruction. This resulted in returning from the ISR to the wrong place. I didn't notice it on first tests because I had just an infinite loop as a main program, and it returned after that loop, where ROM just had $FF, which happens to trigger a reset on my implementation, so it continued working. I was aware of this circumstances, and even have comments on the subject on my microcode, but somehow missed it.

So I have added a couple diode OR gates on the underside and a quad NAND inside a ROM socket (No room to spare!) that enable me to force $FB (unused opcode, now does IRQ sequence) into the IR and prevent PC from counting if an IRQ or NMI was triggered. I had to update the microcode, of course.

Juan

Hi, i just want to give a little recommendation, nothing really related to the topic.

Have you thought about using Logisim Evolution HC instead of the Original Logisim? here the Github Page
it's a branch based of the original but unlike the original (which got discontinued in 2011) Logisim Evo HC is still being updating to this day.
it's a lot more stable and bug free, it can run a lot faster, has a few more components.
and one thing i really like is the ability to show states from a sub-circuit. (with that i mean when you give a sub-circuit a custom shape you can add little "states" which show the contents of registers and counter that are inside the sub-circuit, which is very useful as you can see what is inside a register without having to look inside the circuit.)

here an example where i use those states, to view the Program Counter, Stack Pointer, and General Purpose Registers of my own 6502 based CPU:


overall i would just recommend Logisim Evo HC over the original. you can even load original Logisim circuits with it so converting would be made easier with that. but the size/shape of some components changed so there would still be some issues.
but in the end it's your own choice, i just wanted to throw the idea out there.

I didn't know about that. I'll definitely look into it. There have been some times when I've missed the ability to monitor sub-circuits, and speed is sometimes pretty limiting in the original Logisim. Thanks for pointing it out.

Sorry I haven't posted in a while. I've been busy with university...At least its quite interesting.

Here go a couple of updates:
I have written some subroutines for the LCD and the keyboard. The LCD can now be used as a "dumb terminal", with scrolling and backspace ability.
Basic keyboard input is also working, I'm using a look-up table to translate PS/2 scan codes to ascii, and also modifying input with the shift key. Also I have a control key flag, but not using that at the moment.

The computer seems to work fine, but sometimes it resets itself without apparent reason. I haven't been able to track it down yet.

I'll try to publish the revised schematics, some code and documentation soon. We'll see.
Juan

The whole of Spain has been locked down because of Coronavirus, so we have to remain at home. University is closed, but they keep us busy through online services. So a bit more time to work on this, but not much.

Some updates:

I'll be posting all schematics and code on this GitHub repository:
https://github.com/Juan-Gg/microcoded6502

So far I've updated the Logisim simulation, the microcode, and some of the routines for the LCD and Keyboard that I've written.

I have been doing some testing for a video card.
My requirements so far are:
-VGA, monochrome.
-Has to fit on one of my perfboard cards.
-Usable resolution to work as a simple text terminal.
-As simple as I can get away with.

I have wired up a couple 12-bit counters and some diodes that generate VGA sync signals (I'm amazed that such a mess works). That is for a 800 by 600 resolution, of which I may be using 200 by 150 (divided by 4). That would result in 25 columns by 16 rows of 8 by 8 characters (some amount less than the VIC-20) See attached, each square (and lack of) would be a character.

It would be 25 columns + 7 to complete 32. It's wasted RAM, but simplifies hardware.

A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _
A A A A A A A A A A A A A A A A A A A A A A A A A _ _ _ _ _ _ _

The idea it to have a RAM that holds the bitmap (about 4k), mirroring regular RAM.
As it is quite a low resolution, I suppose I could do all the character generation and scrolling in software.
Just some thoughts. I haven't thought everything trough, but thought I'll post something.
Juan

I have been working on the design of the video card. Here are some preliminary schematics, I now have to do some prototyping to test things out. I'll write more details later. Not so sure about the capacitance of those diodes. Any suggestions are welcome.
Juan

Edit: Some ideas taken from this article: http://www.waveguide.se/?article=bitmap ... -interface.
Edit2: I'm going to use '161s instead of the '4040 binary counters, as I need them to be synchronous. Thanks Dieter for pointing it out.

If you want to test a VGA circuit before actually building it in RL, i'd recommend Digital

It has a component that behaives exactly like a VGA Monitor and it allowed me to test my own VGA video chip.
and the simulated display was identical to the RL one when i tested it.
here a comparation:


the colors are a bit washed out on the RL one but that's more of a monitor thing than a circuit problem.
it also has a lot of 74xx chips build in, so you can build a circuit that you can also do in RL with the same components.

anyways, I'm trying to understand your notes by building the circuit in Digital. (or something very similar to it)

the sync signal is the easiest part to get right. you just count and check, and set the H/Y Sync with some flip flops.
the actual drawing of pixels though, oh boy that took me some time.

a few things i noticed with your design that confuse me a bit.

1. why the RAM chip? as far as i understand your notes it looks like you read from System Memory into your "VRAM" and directly afterwards into the shift register.
so why not skip the middle man and read directly from System Memory into the Shift register?

2. your notes state that everytime the bottom 3 bits (bits 0-2) of the X (ie horizontal) counter are high it loads a new byte into the shift register,
which confuses me a bit as i thought your target resolution was 1/4 of the original one, so you would need to shift everything 2 bits higher, but you still need to check the first 2 bits as well... so you would need to check for bits 0-4 to be high to load new data.

3. this is kinda connected to 2.. because the clock you seem to use for your shift register seems to be the full 40MHz clock, right? technically if you use 1/4 of the original resolution the speed at which you output pixels should therefore also be divided by 4, so the shift register would need to run at 10MHz instead.
that way the pixels are being strechted to be 4 times longer than originally, and each line should also be drawn 4 times in a row. (which seems to be the case in your notes). so that it fills out the whole screen.

ok so, after too many hours... here is what i made based on your notes.
the circuit i made is kinda like me, it's a mess... but a functional mess.

if this circuit were to be implemented 1:1 in an FPGA it should work like you desribed yours.
just without the RAM inbetween, this one generates a Bus Enable signal to disable the CPU while reading from Memory.
also those comparators could easily be replaced by some larger AND gates but i was lazy and wanted it to be more compact.

I hope i explained everything in the image...

maybe it helps you design your own chip with discrete logic ICs, or you'll get yourself some GALs/CPLDs to simplify the circuit and make it smaller.

i really hope it helps atleast somewhat because i actually spend a lot of time designing this and perfecting the timings and everything...

EDIT: oops forgot the download for the Digital Program: DROPBOX LINK

Looks great, I may give it a try.


Keep in mind that:
a) My schematics could use some accompanying text for clarification.
b) I have only done brain-level simulation (which often misses quite a few things)
c) I've got no idea of what I'm doing.


Originally this was meant to be asynchronous, the Video Card would work on clock unrelated to the CPU clock, thus the extra RAM. I'm now working on deriving the CPU clock from the Video Card (for peace of mind), but reading from system RAM would require a way of tri-stating the CPU's address bus (data bus is floating on phi2 low). My CPU currently has no Bus Enable, so that would require additional bus transceivers on the CPU side, which I have no room for (without doing some ugly stuff that is). It just seemed simpler to have a local VRAM.



Horizontal counter is running at 10 MHz, which is also the pixel clock, 1/4 of the 40 MHz pixel clock of the SVGA standard I'm implementing. So yes, my target resolution is 800/4 by 600/4, so 200 by 150. The bottom 3 bits of the horizontal counter dictate when the RAM is read and written to. Each 8 pixels, a new byte is read from VRAM into the shift register. Note that the horizontal counter runs 8 pixels ahead of the actual pixel index (see sync signals diagram on the first sheet), this is to have the VRAM address ready ahead of time to meet the RAM timing requirements. Edit: Also note that I'm taking off pixels from the top and bottom (extending blanking), so actual screen resolution is 200x128 px.



You are correct. I should have clarified that on the schematics (these are just me scribbling ideas on a sheet of paper, don't expect much). Pixels are 4x4 regular pixels, as you state.



Thanks for spending the time. I hope it was a learning experience for you too. I see that you have gone for the full horizontal resolution, as discussed above. That should be easy to change if needed. The image is pretty clear, thanks.
I am planning into getting into programable logic, and this seems a suitable project. But I'm keeping this using discrete ICs, if I manage to get it working. Good thing is that I can change cards easily in my system, so I could make a more powerful Video Card later on.

Juan

Edit: Changed VC to Video Card for clarity.

Some progress:
I've wired up the counters and SR latches on perfboard, and it seems to work fine as seen below. Each square, and absence of would be an 8x8 character. That is a 25x16 characters. The top row is blank, but it's there. It both works on a CRT and on a LCD monitor

Various issues:
-'4040 counters are not synchronous, so I've used '161 counters instead, as I said on a post above.

-Regarding the diode-AND gates:
I've measured voltage drop under a current of 5mA (worst case working conditions) to be just under 0.7 V.
As I'm using CMOS, logic low input threshold is a minimum of 1.35 V and 2.1 V typical (as per the datasheet),
worst case low level output would be 0.1 V, plus 0.7 V gives 0.8 V, which results in 0.5 V margin for noise.
And that is at 4.5 V supply, so with the 5 V I'm working with, the margin should be a bit more.
So not ideal, but I thought that it was safe. It would not work for TTL of course.

That was my reasoning. But adding the 161's required some extra NOT gates, and what do you know, all '04s I have are either LS or HCT, so that won't work. (I've used some CMOS NAND gates temporarily)

-Also, of the 6 '161 counters needed, I had 5 HC left and fitted an HCT one (of which I have more of). Not only are the input thresholds different (which din't matter in this case), but HC parts are significantly faster, so it was causing some glitches. I've fitted all HCT parts on the vertical counter and it fixed the problem.

Juan

beware though, the VGA component has no chill, if your timing is off by a single cycle it will not work, but luckly it tells you exactly how it got the signals, so you can compare it to online to see the correct values. http://tinyvga.com/vga-timing/800x600@60Hz


a) true but i assume it was just quickly made to write down what you had in your mind before you forgot it overnight.
b) hope i helped with the "finished" circuit
c) well i got sort of an idea on how video output works. thanks to me having worked on my own multi-color, tile based video chip. which i think you could try to do as well once you "finished" this first video output thingy.


ok i had to look through the entire thread to get a better idea of what you're working with here. as far as i understood it, you made a 6502 in Logisim, and used that understanding to rebuild it in RL using individual ICs? amazing project my dude.

anyways, i think i'm getting it finally how your system is planned to work. looking at the notes i assumed the Video card would write into itself from System Memory, but it seems it reads both an address and data from whatever is in those 74373's at the top of the note to write a single byte into VRAM. and what that data and address is, is set by the CPU manually...
which is kinda genius but i'd imagine also really slow, especailly since you need 8 bytes of data per 8x8 "tile", plus you need to manually update the address everytime.
one thing i would change is to replace the 2 registers holding the address with a few counters, and everytime the CPU finishes a write it increments the counter. which would make data transfer a bit easier for the CPU.
another thing that would make life easier is some Interrupts. at least i would add 1 interrupt when the Video chip is about to start drawing the next frame, and one when it just finished drawing a complete frame. i'll add a bit more detail to this at the end of the post.*


oh i see so you just run the Horizontal counter at the divided speed so you don't have to throw away bits. i guess it works. I always like to use the full resolution counters for the sync signals and such. just like how i don't like to use shift registers and instead just use a normal 8 bit register with an 8:1 multiplexer connected to it so i can select bits 0 to 7 off it.
then again i don't have to worry about breadboard/perfboard space on a digital design...


i was just confused because of how it looked on your test monitor.


yea it was weird to learn, i'm used to the standard 640x480 resolution because my FPGA dev board has a 50MHz clock, so getting a 25MHz clock for that resolution is easier than the 40MHz for 800x600...
yep, good luck with the programmable logic stuff, it is really worth it. you could probably fit the whole 6502 in like 3-5 cheap CPLDs.
also sorry, but what is VC? only thing i know with that name is "Virtual Console".




*to continue from above
This image is a Pixel perfect representation of a 800x600 VGA screen, it shows the visible area in white, and the various sync and porches in other colors.

This image is based, again, on your notes. they said that the screen is offset by 8 pixels, since your horizontal counter is already divided by 4 it should mean the whole screen is offset by 32 actual pixels. which you can see here. the top left corner is where both counters are 0.
you may also notice 2 black lines near the bottom, those are the places where i would let the Video chip cause an Interrupt, or around that area atleast. if you have vector interrupt it would make this a lot easier.
one interrupt tells the CPU that a frame has just been finished, so the CPU should be able to write into the VRAM in rapid pace as the video chip itself no longer needs to access it.
and the other warns the CPU that it is about to start drawing the next frame so it should probably stop writting into VRAM.

anyways, interrupts are not really important at the time, but just food for thought for the future. :p
also in case you want the colors:

I'll be getting into more complex video cards later on, no doubt. But using programable logic.



Thanks!. This video card is supposed to catch writes to regular RAM in some range of addresses, and write that same data to its own VRAM, thus mirroring regular RAM. The addresses are set by the address bus, they are not set manually by the user, you just write to a memory location, and it should store the data in both regular RAM and VRAM.

These are good reads:
http://www.6502.org/users/dieter/drc2/drc2.htm
http://www.waveguide.se/?article=bitmap ... -interface


The first image I posted with the CRT was using my earliest design, which had some timing issues, that's why some thin strips of blue appear on both sides of the screen.




I just happened to have a couple 10 Mhz oscilators around... Sorry, VC is just me saving characters. i meant Video Card. Just changed it on the original post.



Seems correct to my understanding. Thanks. I may add an interrupt at the end of every frame, or a counter to use as a timer for the computer. My CPU is running at 1 MHz, and because of my implementation, that is more or less equivalent to a 6502 running at 500 KHz. So it's not really fast. I haven't thought of writing on the vertical blanking interval, its a neat idea. One could write to regular RAM, and copy the data to VRAM during blanking. The problem is that the blanking interval is around 3000 CPU clock cycles, so I would have to update the screen only a few lines at a time... It seems simpler to me to just catch regular writes. And i don't mind much if I see some display artifacts. I just want to get something simple working.

I'm using the same website for timing information.

-----------------------------------------------------------------------------

Regarding clock derivation from the video card, that would have to be 10 MHz/8 = 1.25 MHz, or half of that, 625 KHz.
I have tested my CPU to run "reliably" up to 1.4..1.5 Mhz, when it starts behaving erratically or even refuses to reset properly. Running it at 1.25 Mhz seems a bit too tight (about 10% lower), especially if that limit changes with temperature and such, which it will. But running it at 625 KHz may be a bit too slow, specially for scrolling the screen and such. We'll see.

I also thought that I could save color information for each horizontal line on the unused RAM at the end of each line, so that would set an 8 bit register with color information (4 bit foreground, 4 bit background), that would take effect on the following line. The first line would have color information stored on the last line. Just an idea, it's just a nicety I can do without. But seems a simple way to add some color.

Juan

oh, then i misread it. i thought the user would have to manually access the VRAM through those 3 D-FFs, kinda like how some other video chips have VRAM on their own seperate bus, and you can only access it via some internal registers inside the Video chip itself.


i see, so it was just convenience.



ironically that is around how my video design works, it has an internal frame buffer that it uses somewhat like your VRAM.
during vertical blanking it reads out all the data it needs for the next frame, and during drawing that frame it doesn't interact with the system bus at all... it means the CPU has more uninterrupted cycles while the frame is being drawn but stops the CPU for some time (~1.4ms at most) while accessing System Memory (or not if you only stop the CPU if it tries to access that part of memory and otherwise just let it run normally).
it sounds more complex than it actually is. but i'm getting a bit side tracked again...


yea makes sense, once you got something basic working you can throw on new features, fixes, changes, etc.


speed is always an issue, this is why i think a tile based video chip for next time would be a good idea. it means you have to move less data, but the circuit is more complex, too complex i'd say for breadboards.
also maybe looking into some High speed 74xx logic chips could be helpful. the AHC parts seem pretty good.
just comparing the SN74HC541 to the SN74AHC541 as example.
SN74HC541, time between pulling OE low and the output being stable: ~38ns
SN74AHC541, time between pulling OE low and the output being stable: ~16ns
unless i'm reading the datasheet wrong...


that would be something, also an interetsing limitation to have 2 colors per line. but i think it would be better to wait a bit until CPLDs and such before getting into color circuitry

.

also if you can spare the money, you could just get some dual port RAM, it's like normal RAM but has 2 data and address ports so 2 seperate devices can read/write to it at different addresses at the same time.
so one side is connected to the CPU bus... for the CPU, and the other is connected to your video chip. no need to catch Write cycles, you just read a byte from RAM and throw it into your shift register, it makes the circuit much easier.
only downside, it does get quite expensive the more you need. i found this PLCC SRAM chip on digikey (LINK), 2kB, 55ns read/write, and 8 EUR per chip. that's ~16 EUR for your 4kB Video Memory, but would mean you could get rid of that extra VRAM chip and probably some other chips as well

just an idea though

As we know from this very forum, there is (at least for Radical Brad) seemingly no VGA video system that is too complex for breadboards. :-)

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

That is both really impressive and horrible at the same time. bravo to the guy with enough patience to do this!

I know it would be easier. And I could assume the extra cost if I had to. (Even knowing that 16 € would be over the cost of the entire current video card). I don't really want to think how much is this computer going to cost...But that is beside the point.

As my primary goal is learning, I'll try to solve the problem with the parts I have. But dual ported RAM is an option to keep in mind. Maybe for a faster design.


I've read his posts. I also remember browsing his website as a kid (http://www.lucidscience.com). I'm definitely aiming much lower here...

------------------------------------

Some updates:
I've thrown in a ROM filled with random data to try out the shift register loading and shifting pixels. It sort of worked. I somehow assumed that the shift register would keep its output unchanged until the next clock pulse, but obviously, when it's being loaded it doesn't. This caused some vertical blank lines on the output, see attached. The shift register was shifting one pixel too early, and first pixel of every byte was too short, as the register had to be loaded. On the scope screenshot, the yellow trace is the shift/ld, and the dark blue trace is the output from the shift register. Bright blue is one of the data bits from the ROM I think.
I temporarily fixed it by delaying the shift/ld pulse with an RC network, and feeding the A input of the shift register to its own serial input. This reduces the with of said black lineas and extended the last pixel of each byte to fill them entirely. It works, but it is nothing more than a bodge.
Adding a flip-flop makes it work as I originally intended, so I think I'll add the extra IC. I've tried with another shift register acting as a flip-flop on a breadboard and it works flawlessly. Well, there is a bit of an extra pixel at the end of each line, but that shouldn't be too difficult to fix. See last photo.

I'll see if I can get the foreground and background colours working, so I don't have to rely on an external breadboard to attach the VGA cable. Then, it'll be time for RAM writes from the CPU.
Juan

Edit: Forgot a couple things here and there.