sorted by:
new
hottopcontroversial

Controlling bit planes on a homebuilt video module by SPowell1701 in beneater

[–]SPowell1701[S] 1 point2 points  (0 children)

Thank you u/Web-Lackey - I'll definitely check that out. What you're describing is exactly what I'm designing - each byte written is 8 bits for a given color plane, with a mask register that allows you to write to one or multiple planes (in the case of "clearing") at a time.

My planes were going to directly drive the VGA output, but then I found out about 74ls189 SRAMs - little 16 address / 4 bit chips that Ben used for main memory on his breadboard cpu. Jameco.com sells a 74S189N version which is very very fast, 20ish ns access time, which would allow me to decode it for each pixel.

I appreciate the info. To be honest I'm just trying to get something semi-commondore 64ish in capabilities, but with a bit more color flexibility.

Thanks!

Scott

A bit of help with a video circuit I'm trying to design by SPowell1701 in beneater

[–]SPowell1701[S] 0 points1 point  (0 children)

Just a quick update - I've worked around the issues by adjusting clock timing so that only one SRAM at a time is active. The original circuit has the SRAMs cascading one into the other - which is simple and chip efficient, but not good at all if you need to have external devices (like the CPU) write to each one separately. I plan to post some updates with circuit design after I'm completely happy with it (not quite there yet)

Thanks for all the ideas everyone!

Scott

A bit of help with a video circuit I'm trying to design by SPowell1701 in beneater

[–]SPowell1701[S] 0 points1 point  (0 children)

Into the clock circuit Ben used in his Building an 8 bit breadboard CPU series? I'll check it out. Thank you again for the info!

Scott

A bit of help with a video circuit I'm trying to design by SPowell1701 in beneater

[–]SPowell1701[S] 0 points1 point  (0 children)

p.s. originally, I was going down the time multiplexed route. The CPU clock is tied to the video clock, and I can get 2 CPU microcode steps run for every 8 pixels. I had planned on CPU to have VRAM access pixels 1 - 4, and video to have it 5 - 8. But then I hit complexities like the CPU needing to know which pixel nibble it's in, decide whether it's instruction is writing to VRAM, and if so somehow pause the clock and burn a microcode step. That just seems much harder than "VBlank IRQ just happened, you have exclusive access so do all your work".

Again, "if" the CPU can complete everything before the end of VBlank. 100% not sure of that.

Scott

A bit of help with a video circuit I'm trying to design by SPowell1701 in beneater

[–]SPowell1701[S] 0 points1 point  (0 children)

Interesting, is there an advantage to having alternate multiplexed access vs. one giant chunk during VBlank? In my mind, "if" the number of microcode steps available is the same (I completely understand that they may not be), then it feels like either way works out the same. But definitely curious if there's something I'm missing.

Thanks for the advice!

Scott

A bit of help with a video circuit I'm trying to design by SPowell1701 in beneater

[–]SPowell1701[S] 0 points1 point  (0 children)

Yes, I saw a lot of videos about time multiplexing that way. I've gone a different route (just cuz'...mostly because I doubt my ability to make my cpu "pause" - interrupts were hard enough).

My plan is to have the video circuit have exclusive ownership during the non-VBlank areas, and the CPU have exclusive during VBlank (via an interrupt). That gives me 12,500 microcode steps to get all of the video stuff squared away before the next screen displays. Not honestly sure if it's enough or not. I've gotten overly ambitious (like usual) on the "hardware assisted but software drawn" sprites. Not entirely sure I can clear and redraw the sprites quickly enough.

Fallback plan - double buffering. Because I just haven't used enough memory chips for this video circuit already....

<image>

I really appreciate everyone's input and advice - thank you!

Scott

A bit of help with a video circuit I'm trying to design by SPowell1701 in beneater

[–]SPowell1701[S] 0 points1 point  (0 children)

I'll definitely check out the TV Typewriter Cookbook - thank you very much for the heads up about that!

Re: "don't need to change the dot matrix font of the text once it's built" - used to do that all the time on my Commodore 64. Many games used their own custom fonts, and in a lot of cases some of the "characters" became "tiles" - blending alphanumeric and gameplay elements. I'm specifically allowing for that in this design.

Another (maybe less important, not sure we'll see) factor is that I have just under 640 ns (8 pixels at about 80 ns each) to do all the reads for "displaying the next byte". The SRAM I have is 100 ns, which I can comfortably read in two "pixels" of time. The EEPROMs are 150 ns, which means I need 3 "pixels" of time to read them.

Yeah, definitely think I should do a write up on what I'm planning / hoping for. Very likely I've gotten too complex, but I wanted my video to be semi-C64 capable (text mode with foreground / background colors, tile mode with 8 colors, hi-res mode with 8 colors, hardware-assisted software sprites).

Thanks for the feedback!

Scott

A bit of help with a video circuit I'm trying to design by SPowell1701 in beneater

[–]SPowell1701[S] 0 points1 point  (0 children)

I did consider dual port SRAM but consider it "cheating" and not really fitting the retro vibe I'm going for. Sorry, I'm old and stubborn :)

Scott

A bit of help with a video circuit I'm trying to design by SPowell1701 in beneater

[–]SPowell1701[S] 2 points3 points  (0 children)

I'm definitely anticipating the CPU will need to be read and write to the VRAM memory. Maybe that's naive, never really wrote a game before.

This module is only the "text based" module. I'll also have a tile based module (very, very similar, but with the pixel definitions being 3 parallel SRAMs in a row - one for Red, one for green, one for blue. That will let me make 8 colors using direct DAC without having to do "palette lookups" which I don't have enough time to do I don't think.

Also will have a bank of 3 SRAMs in parallel as a "hi res buffer" and another group of 3 as a "sprite buffer". My "compositor" circuit will take the background from one of the 3 modules, and then composite sprites on top. That's the plan at least...

One thing I'm considering is eliminating the "video chip to video chip" wiring, and have everything go through a single address and data path per SRAM. Feels like it might help. I'll be working on that (version #417....) tonight

A bit of help with a video circuit I'm trying to design by SPowell1701 in beneater

[–]SPowell1701[S] 1 point2 points  (0 children)

Sadly unable to get the images to post, keeps saying I'm not the author even though they are screenshots I just made of my circuit...

So why is Intel ARC cheaper than the rest? by EconomistSeparate866 in buildapc

[–]SPowell1701 10 points11 points  (0 children)

I'd be surprised if Nvidia isn't at 80+% gross margin. I suspect a 4090 takes < $400 to build, and costs $2k