Introduction

Anything that does not belong in the above categories.
ysblokje
Posts: 18
Joined: Fri Aug 14, 2020 8:06 am

Re: Introduction

Post by ysblokje »

You mean 320x200x8b (linear mode, 256 colors)? So I guess you never had to go with planar mode with SET/OR/AND/XOR operations? Yeah, that linear mode was a blessing when it comes.
Yeah mode 13 or mode X (320x400 if I remember correctly) No planar mode for me, and it sounds absolutely horrible and slow. But I will try to make that starfield thingy I promised myself I would write ;)
psmart
Posts: 138
Joined: Thu Nov 21, 2019 10:12 am
Location: Leeds
Contact:

Re: Introduction

Post by psmart »

Welcome as well. It is probably easier just to write your own video hardware in VHDL, that way programming it can be as hard or as easy as you deem fit :) - ie. The board Im making below, recreates the MZ700 (/80A/80B) video hardware in the FPGA along with 640x200 pixel graphics 8 colour (due to lack of RAM inside the FPGA, otherwise would be xxx colours).
Attachments
tranZPUter-SW-700_v1_2.png
Last edited by psmart on Sun Sep 06, 2020 5:42 pm, edited 2 times in total.
Sharp MZ/X Series Projects and FPGA Emulator
engineers@work : https://eaw.app/sharpmz-series/
psmart
Posts: 138
Joined: Thu Nov 21, 2019 10:12 am
Location: Leeds
Contact:

Re: Introduction

Post by psmart »

arnuphis wrote: Tue Aug 11, 2020 4:45 pm Thanks! I ordered a bag of cassette player belts of various sizes. So hopeful that one of them is the right length!
I forgot to look at my MZ80B, sorry about that, got carried away with my projects!!! Did you ever get the MZ80B tape drive to work?
Sharp MZ/X Series Projects and FPGA Emulator
engineers@work : https://eaw.app/sharpmz-series/
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: Introduction

Post by hlide »

psmart wrote: Sun Sep 06, 2020 5:11 pm video hardware in the FPGA along with 640x200 pixel graphics 8 colour (due to lack of RAM inside the FPGA, otherwise would be xxx colours).
Hi psmart!

may I suggest a thing? when I was on BrickBuster game, I was trying to get more than 8 colors without hardware add-ons. The idea was chang
ing the color between frame in a similar fashion than http://www.aaronbell.com/secret-colours ... HoV_Gui5wA . But the issue is modern TV has their own frequency and it doesn't go well.

Here are two videos to show you the issue: the top window is my emulator that emulate the hardware color blending while the two bottom windows are just doing software color-blending. My TV being a 60Hz, even the NTSC version is not totally in phase.

- https://www.dropbox.com/s/b2kj1vsr0n5d5 ... 8.mp4?dl=0
- https://www.dropbox.com/s/sovwflbytozwk ... 0.mp4?dl=0

So why not to offer the ability of color-blending with your video output by adding a flag to set to activate it?

Technically, we want colors A and B in a frame sequence ABABABAB...AB to be CCCCCCCC...CC. AB or BA should give us the color C through a fix palette. C is among 36 colors (8x8/2 + 8). Just computing (A+B)/2 as it was in the emulation is not great. Having a more refined palette would be awsome.

And now a picture what it gives when you mix two different characters between frames using color-blending:
2020-09-06_21-00-50.png
2020-09-06_21-00-50.png (18.58 KiB) Viewed 9335 times
psmart
Posts: 138
Joined: Thu Nov 21, 2019 10:12 am
Location: Leeds
Contact:

Re: Introduction

Post by psmart »

Hi Hlide,

Very interesting read, thank-you

I will have to consider how to do it as the BRAM is limited in the FPGA I chose. As you mentioned, a palette register could be employed, and if enabled, flip the actual colour bits on each frame with a 50% or even a programmable duty cycle (ie. red 50%, blue 50% = purple, or red 25%, blue 75% etc). Not sure how much flicker will occur especially with varying duty cycles, but all outputs, including the original Sharp, are at 60Hz so should work. I chose 60Hz to keep the pixel clock frequencies down on the external display (ie. 65MHz for 1024x768x60Hz or 40MHz for 800x600x60Hz) and it appears the higher frame rates are better for this technique.

Adding an additional 640x200 to enable a selectable palette at the pixel level isn't possible, but grouping pixel blocks or just a selectable screen level palette is possible, I will make some trials on the MZ80A and see what happens and let you know.
Sharp MZ/X Series Projects and FPGA Emulator
engineers@work : https://eaw.app/sharpmz-series/
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: Introduction

Post by hlide »

Well, that thing was for the MZ-700 text outpout. The point is the palette (in discreet viewpoint) can be a ROM getting the current internal RGB output (A/B - 3 bits) and the previous internal RGB output (B/A - 3 bits) as input and outputs C color (6 bits, the pair of which are merged into an analog voltage - SCART or VGA). If you do that for the text output (VRAM text and VRAM atrributes), it means you need 320x200x6-bit to save the the pixels of the previous frame and use them to mix with the current internal pixel to output the current final pixel. That's about 64 KBytes for the visible part.

To be honest I'm looking for a hardware implementation which gets the RGB signals and some other signals like blanking to save it in one of two SRAM. The vertical blanking will be used to toggle SRAM usage and to clear the address counter. The horizontal blanking to disable the address counter increment par pixel clock. 1-bit R, G, B inputs X will be saved in one SRAM. The previous 1-bit R, G, B inputs Y will be read from the other SRAM using that address counter and fed with X as inputs to, say, a ROM (fix palette) to get 2-bit R, G, B outputs Z. Then each pair of R, G and G bits of Z are mixed into an analog voltage.

I wonder whether it would be possible to connect analog RGB on the video box (composite, DIN-8, etc.) so it can render more than 8 colors on usual video output or the fact the video box wants to deal with TTL signals and so would transform the analog signals into TTL and so wouldn't be able to give more shades than the usual 8 colors.
psmart
Posts: 138
Joined: Thu Nov 21, 2019 10:12 am
Location: Leeds
Contact:

Re: Introduction

Post by psmart »

One of the advantages using the FPGA is you build the frames and can manipulate them, harder to do in physical hardware as your encountering. In the FPGA I have a frame-buffer which I render during the blanking periods (H/V) at 120MHz, either 320x200x3 or 640x200x3, the number of frames per second depends on the driving vertical frequency, the VRAM/Attributes get read and rendered into the frame-buffer and blended with any existing direct pixel writes during this rendering period. All the memory is dual port so as not to cause snow/tears. The video output is made in a separate process and if driving an external VGA display I make basic pixel duplication (ie. 320x200 on a 640x480 doubles the H and V pixels).

It should be easy enough to instantiate a palette register which adjusts the colour of the pixels based on the technique you mentioned, just keep a counter on the frame being rendered and then adjust the pixels being written to each of the RGB frame-buffers according to the palette value.

I started to look into it but then discovered a design flaw in my Video Module which Ive been trying to resolve! Once resolved will look further at this technique.

Regarding the MZ-700, the RGB signals are digital from the mainboard and are routed direct to the 8pin DIN. Inside the modulator, after buffers, they are converted into analogue using a resistor network before driving the modulator/Composite video.

On the MZ80A Video Module I used a 4x3bit RGB signal to allow for true palettes but on the MZ700 board Im working on I overlooked the above observation (8pin DIN being driven directly from the mainboard connector), so I will make some updates to add 4x3bit RGB and this will allow driving an analogue RGB monitor/VGA monitor.

If you don't have much success with your hardware palette resolution I can let you have one of my boards when complete (no cost) if your interested. I'm not making any of these for profit, just for learning and Im tending to make at least 2-3 as it is still quite tricky working with the QFP packages, you never know if you have a software/vhdl or physical issue when a bug occurs, so being able to swap the boards around helps. On some of the previous boards Ive had to use flux and a hot air gun on some of the QFP packages as the solder type/quantity during the SMD stencilling isn't as reliable as I would expect, would be nice to have a pick n place machine for these devices!!! If you look at the boards I've started putting pin numbers on the QFP packages to make it easier due to the hours spent connectivity testing.
Sharp MZ/X Series Projects and FPGA Emulator
engineers@work : https://eaw.app/sharpmz-series/
hlide
Posts: 681
Joined: Thu Jan 25, 2018 9:31 pm

Re: Introduction

Post by hlide »

That's just an idea I had because modern TVs don't like at all when a pixel is alternating colors. So I wanted to avoid the color gradiant through flashing done to the screen because the bigger the difference of luminosity between two alternate colors is, the uglier the pixel flashes. So I thought the color can be created BEFORE reaching the screen as it would remove the flashing effect whatever the screen is. I'm far less confident and competent to make it though.

I was waiting for you to terminate your project before asking if there is a way to get one, so I would certainly not refuse your offer :). My hardware realizations are very simple and I tend to keep them as simple as possible (IPL 512KByte, Western/Japanese CGROM switcher, MZ-SD²CMT using Arduino MEGA) because I'm not fluent in electronics but I sure like that hobby.
arnuphis
Posts: 59
Joined: Fri Jul 31, 2020 4:18 pm

Re: Introduction

Post by arnuphis »

psmart wrote: Sun Sep 06, 2020 5:12 pm
arnuphis wrote: Tue Aug 11, 2020 4:45 pm Thanks! I ordered a bag of cassette player belts of various sizes. So hopeful that one of them is the right length!
I forgot to look at my MZ80B, sorry about that, got carried away with my projects!!! Did you ever get the MZ80B tape drive to work?
No problem. It's quite alright. I got everything back together and still have the same issue. Shelving it for now until I can source another MZ-80b or a cassette deck. At least everything else seems fine with it.
psmart
Posts: 138
Joined: Thu Nov 21, 2019 10:12 am
Location: Leeds
Contact:

Re: Introduction

Post by psmart »

hlide wrote: Tue Sep 08, 2020 4:29 pm I was waiting for you to terminate your project before asking if there is a way to get one, so I would certainly not refuse your offer :).
Just a quick update, I've been in Austria for the last few weeks so I haven't completed everything yet, but the pictures will give you an idea. All functionality works so far but I have still to make several changes to the VHDL in the FPGA/CPLD for the graphics. At the moment, standard video works,the tranZPUter part works so loading from SD card etc. Probably end of month but will update my website www.eaw.app and forward a board to you.
Sharp MZ/X Series Projects and FPGA Emulator
engineers@work : https://eaw.app/sharpmz-series/
Post Reply