MiSTer FPGA Forum

I’d like to take a stab at adding vertical flip to a few arcade cores that are missing it (Roc n’ Rope, Gyruss, etc). But before I go down this rabbit hole I wanted to get an idea on the level of difficulty. I’m an old school programmer from the early 80s. I have COBOL, C, C++ and a tad of assembly experience. I know just enough to get in trouble, I wouldn’t call myself an expert but maybe somewhere between intermediate and advanced skill level. I wrote a driver for MAME a long time ago. I know this is nothing like MAME, this is hardware level programming in VDHL or whatever but do you think I have enough knowledge for something like this? Or is it better to politely beg one of the current core developers?

I don't know if you have the knowledge, but from a standpoint of taking on a challenge and a learning experience - I'd say go for it. What have you got to lose? Only time. You might gain some insights along the way that will help you in other areas. Good luck.

My personal 100% anecdotal experience coming from a similar background is that almost none of your computer programming knowledge carries over to FPGA programming. I gave up on FPGA programming (for now) because it seems you need to know much more about electronics rather than programming to become proficient at it, and that's not something that I have the time for right now. Sure VHDL/Verilog appears as code, but it's nothing similar to what you're used to from programming a CPU to do tricks for you.

I concur with bazza, nothing to lose by giving it a try. However... It's certainly not the simplest way into learning core development!

The level of difficulty in implementing vertical flip will vary hugely depending on the way the original hardware draws to the screen. If you are lucky and the system uses a frame buffer (like Juno First which I'm currently trying to finish!) then it's pretty easy - just a case of changing the addressing logic for the screen RAM. If it draws things line by line, with a mix of different subsystems like sprites, tile maps, and character maps, it could be anywhere from really hard to impossible!

A way to get an idea of what is involved would be to find a core that has already had it added at some point, and look into the git commits to see what was changed to achieve it.

Best of luck if you decide to do it, we always need more devs

jimmystones wrote: ↑Thu Jul 13, 2023 3:41 pm

I concur with bazza, nothing to lose by giving it a try. However... It's certainly not the simplest way into learning core development!

The level of difficulty in implementing vertical flip will vary hugely depending on the way the original hardware draws to the screen. If you are lucky and the system uses a frame buffer (like Juno First which I'm currently trying to finish!) then it's pretty easy - just a case of changing the addressing logic for the screen RAM. If it draws things line by line, with a mix of different subsystems like sprites, tile maps, and character maps, it could be anywhere from really hard to impossible!

A way to get an idea of what is involved would be to find a core that has already had it added at some point, and look into the git commits to see what was changed to achieve it.

Best of luck if you decide to do it, we always need more devs

Thanks jimmystones! I’ll definitely take a look at what was done previously on cores to get flip added

netbeui wrote: ↑Thu Jul 13, 2023 4:28 pm

jimmystones wrote: ↑Thu Jul 13, 2023 3:41 pm

I concur with bazza, nothing to lose by giving it a try. However... It's certainly not the simplest way into learning core development!

The level of difficulty in implementing vertical flip will vary hugely depending on the way the original hardware draws to the screen. If you are lucky and the system uses a frame buffer (like Juno First which I'm currently trying to finish!) then it's pretty easy - just a case of changing the addressing logic for the screen RAM. If it draws things line by line, with a mix of different subsystems like sprites, tile maps, and character maps, it could be anywhere from really hard to impossible!

A way to get an idea of what is involved would be to find a core that has already had it added at some point, and look into the git commits to see what was changed to achieve it.

Best of luck if you decide to do it, we always need more devs

Thanks jimmystones! I’ll definitely take a look at what was done previously on cores to get flip added

Make sure the examples you use implement the screen rotation like hardware, some do not. Here's an example from the same period as the cores you're looking at.

https://github.com/va7deo/TerraCresta/c ... 5e6fd39bb6
https://github.com/va7deo/TerraCresta/c ... 9c9fcc7cba

atrac17 wrote: ↑Thu Jul 13, 2023 7:17 pm

Make sure the examples you use implement the screen rotation like hardware, some do not. Here's an example from the same period as the cores you're looking at.

https://github.com/va7deo/TerraCresta/c ... 5e6fd39bb6
https://github.com/va7deo/TerraCresta/c ... 9c9fcc7cba

Thanks for this! I started off looking at Dig Dug, just randomly picked that one. I appreciate your reply to get me started in the right direction.

Any idea where I can find the source for Roc n' Rope? I think it's a Jotego core, but not sure if it's closed source. All I found so far is this: https://github.com/jotego/jtbin/tree/ma ... c/releases

Roc n' Rope is a part of the Kicker core - https://github.com/jotego/jtkicker

"Coming from a programming background" is no excuse not to attempt FPGA coding.

You can use VHDL / Verilog to describe hardware in detail and keep everything as close to the original design as possible
something like this from Galaxian core :-

u_8n : entity work.LOGIC_74XX138
port map (
	I_G1  => '1',
	I_G2a => I_RDn,
	I_G2b => MEM_SEL,   -- <= *1
	I_Sel => I_CPU_A(13 downto 11),
	O_Q   => W_8N_Q
);

O_WDR_OE      <= not W_8N_Q(7);
O_DIP_OE      <= not W_8N_Q(6);
O_SW1_OE      <= not W_8N_Q(5);
O_SW0_OE      <= not W_8N_Q(4);
O_OBJ_RAM_RD  <= not W_8N_Q(3);
O_VID_RAM_RD  <= not W_8N_Q(2);
O_CPU_RAM_RD  <= not W_8N_Q(0);

Where the code is doing the memory address decode using the original chip (and LOGIC_74XX138 is a unit being used)

or you can implement in a way that is more like you would have done in a programming language but yields the same end result
from Crazy Balloon :-

            address := to_integer(unsigned(cpu_addr));

        rom_rd <= '0';
        ram_rd <= '0';
        vid_rd <= '0';
        col_rd <= '0';

	if cpu_rd_l='0' then
		case address is
			when 16#0000# to 16#3FFF# => rom_rd <= '1';
			when 16#4000# to 16#43FF# => ram_rd <= '1';
			when 16#4800# to 16#4BFF# => vid_rd <= '1';
			when 16#5000# to 16#53FF# => col_rd <= '1';
			when others => null;
		end case;

I'm from a programming background, but I do understand (most) digital circuits as well - it's only code written with logic chips

I also program, and do programmable logic. And, my biggest problem with the FPGA is clock skew / domain issues...

As others have said, it's not an ideal first project, but you can probably pull it off if you're reasonably persistent and curious.

Coming from a software perspective, the biggest potential pitfall I'd suggest watching out for is that while most video hardware has a fairly obvious vertical position counter somewhere, simply reversing that counter probably won't work. Most video hardware is set up to count extra "pixels" and "lines" that don't actually correspond to graphics data, and use those values to generate control signals (e.g. backdrop enable, blanking, sync, IRQ). Those signals generally need to be consistent regardless of which way the graphics are flipped, and video hardware is typically set up to alter the control signals when the counter hits specific values (depending on the system, these values may be programmable by the CPU or hardwired). You'll likely either need to pick out the line number as it's presented to the address generation logic for some video memory and reverse that, or reverse the V counter and code an alternate set of conditions for flipping the related control signals. As jimmystones says, the overall difficulty and the best approach depends a lot on how the system is structured.

If you happen to find yourself generally lost on old-school video generation/timing concepts and don't mind YouTube lectures as an educational format, Ben Eater's "world's worst video card" is about as good an introduction to the fundamentals (and some of the jargon you might see in HDL sources and hardware documentation) as you're likely to find anywhere.

https://www.youtube.com/watch?v=l7rce6IQDWs
https://www.youtube.com/watch?v=uqY3FMuMuRo

ExCyber wrote: ↑Sat Jul 15, 2023 12:47 am

If you happen to find yourself generally lost on old-school video generation/timing concepts and don't mind YouTube lectures as an educational format, Ben Eater's "world's worst video card" is about as good an introduction to the fundamentals (and some of the jargon you might see in HDL sources and hardware documentation) as you're likely to find anywhere.

https://www.youtube.com/watch?v=l7rce6IQDWs
https://www.youtube.com/watch?v=uqY3FMuMuRo

Amazing how the first video almost exactly describes the inner workings of the Jupiter ACE video display circuitry The idea is exactly the same. The timings are different, as the signal is designed for a PAL composite video output; the counters are 74LS393 instead of 74LS161 (8 bits per chip instead of 4, which I don't know why Ben Eater didn't use) and some gates differ, as the ACE doesn't use 8-input NAND gates for that purpose, but instead uses some trickery to get the signals it needs, and there's no vertical front/back porch, only horizontal, but overall, the idea is identical.

Here's the schematics of the Jupiter Ace:
http://web.archive.org/web/202212261845 ... icScan.jpg

The three big ICs at the bottom right (Z9-Z11) are the counters, the gates below them are the ones that reset the counters and generate the sync signals. The inputs to Z25 (the one with the /SYNC output) are the horizontal and vertical sync signals. The vertical sync is also used to generate an interrupt, through gate Z19 (the one at the far bottom right).

But back to the topic, I'd suggest to take a look at the Template_MiSTer repository, which is a functional core, and try to use it to learn how video is generated (in this case an almost bare-bones video noise simulation with some sine wave modulating it to produce a more "credible" effect).

Don't forget about Time Pilot '84!

Most importantly, thank you for being willing to sink some of your time in this project!

It's probably a pretty difficult project since blackwine and jimmystones have already gotten most of the low hanging fruit.

Thanks for all the tips and suggestions! Wouldn’t you know though, just when I thought I’d have some free time to devote to this my day job suddenly gets ridiculously busy

I know a way to use the MiSTer scaler, but it's hacky and I do not recommend it unless it is for a custom builds

It introduces a frame of latency as it relies on the MiSTer framebuffer. I don't care if I use it for an Apple II or 2600 cores, but it would be problematic for some other systems.

Aspect ratio is also hard to get right. I didn't bother tweaking it so it is a bit off, breaking scanlines. For my use case (running Apple II games on my arcade cab with a spinner) it doesnt matter too much... but you wouldn't want to commit that to a core's official repo.