Emulations for Retro Computing... what video and how?
Cluso99
Posts: 18,069
There are now a lot of emulators coming out. I am interested to know what video is required for each of them.
Which emulation... ?
1. Is it mono or color ?
2. If color, how many color bits ?
3. How many pixels (cols x rows) ?
4. Is is directly accessed or via a seperate terminal ?
5. Should it be VGA or TV (composite video) ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Which emulation... ?
1. Is it mono or color ?
2. If color, how many color bits ?
3. How many pixels (cols x rows) ?
4. Is is directly accessed or via a seperate terminal ?
5. Should it be VGA or TV (composite video) ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Comments
The video signals vary too. Most are single frame, non-interlaced video. Color signal varies, from a simple color burst only on Apple, to interlaced signals with interlaced (phase change) color, on NES.
Pixels range from 64 to 320, with a few punching above that at 512, 640. Most of the even multiples of 8 pixels are well represented, with the exception of Apple, using 7 pixels per byte, not 8.
Memory mapped video is the norm. Pixel depths range from 2, 4, sometimes higher, but not often. Color is mapped all over the place. Some computers used registers and complex CPU timing, others used color memory, with that memory being on a byte, or cell / tile basis.
Z80 and 6502 were dominant, with the 6809 appearing in the color computer. Clocks ranged from 1 to 4 Mhz.
Ram sizes ranged from a few K to 128K stock, with many machines operating nicely with 48 or 64K RAM.
Terminal I/O was not common. It could be done on CoCo, assuming it was running FLEX, or OS/9. Some computers bolted on the older CP/M, in the form of a card, using terminal I/O to get video done, those would do a terminal too. I never spent a lot of time on TRS-80 machines, but it appears others here have that well covered. I did spend time on Atari, C64, CoCo, TI (a beast), early Spectrum, Apple, some MSX.
Any of the more complex displays were memory mapped, with multiple regions of memory contributing to the display. Some computers had fixed pages (Apple), others had dynamic ones, Atari, C64, others...
Typical regions were font / character definition, bitmap screen memory, sprite memory, color memory. Some computers didn't feature user definable characters (Apple, CoCo). Most did.
IMHO, each one will likely require it's own video, if all the features are desired.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 5/11/2010 5:09:27 AM GMT
If we were to take a careful look at the various video formats used we may find that it would be possible to map them to a smaller number of standards that would work with the displays available today. Start with a table of resolutions for the various formats.
If anyone has any video format documentation they can PM me with it and I will get the table started.
If we could create a video driver that emulates the control registers of an 6845, that would save a lot of work for many computer emulations. The exact wiring of the memory address and raster address (character lines) bits was different, though. This resulted in different memory layouts of the video RAM. Also the way a fixed (ROM) or variable (RAM) character generator was addressed was varying, and of course the colour management also differed between the machines.
If the 6845 registers would be emulated, you could change the horizontal resolution from 1 character to abt. 50 characters (8x) per row, so a basically 400x300 display (800x600 display with double width and height pixels) could be the base for the emulation. You could horizontally and vertically shift the display by adjusting the sync position registers. The positions are in units of fixed character width (usually 8 bits) and the selected character height (also usually 8 for text modes). Some machines did a graphics mode by setting the "scanlines per character" to 2 or even 1, thus addressing much more video RAM and combining 2 or more bits into 4colour or even more colour pixels of lower horizontal resolution.
The question is, if it is possible to re-calculate a Propeller video timing based on a set of 8 bit values that is stored in the virtual registers of an 6845. It's certainly not all too easy, while it should be possible to do that.
Here's the layout of the 6845 registers:
Note the MSB first arrangement of word sized addresses, which is Motorola like (and not Z80 or 8086). The total and sync position values would be translated to porch lengths and extra blanking to achieve the configured display size and position. The address counter was 14 bits and so you could address 16KB of memory with the raster address lines (e.g. RA0..RA2) going to a character generator, or you could use some or all raster address lines as memory address lines and extend the addressable memory. I think the CPC464 and CPC6128 did this and also the somewhat odd addressing of the PC CGA graphics modes was a result of using RAx bits for memory address lines.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/11/2010 3:22:34 PM GMT
There are some useful elements:
Bitmap graphics are either linear, sequential, with the exception of the Apple ][noparse][[/noparse], which basically requires a lookup table because Woz found out he could save an address decode chip... or, they are mapped character style, where the first 8 bytes of screen memory appear upper left, 4 or 8 pixels of display and the pixels map vertically down for 8 scanlines. The next 8 bytes would be the next character over, again filling vertically for 8 bytes.
A lot of the home computers worked off of multiples of the NTSC color period. Pixel clocks equal to one NTSC color cycle will do most all the graphics. One thing I find distracting is the interlaced color in the Parallax driver. It's great, because a display can just be scaled, but there is a lot of dot crawl that degrades moving objects.
If we call that period a "color clock", then most of the computers used either 20, 32, or 40 bytes per screen line, representing 128, 160, 256, 320 pixels of data, at one or two bits per pixel. Lower resolutions are multiples of the color clock, 64, 80, etc....
For TV, I highly recommend the templates that Eric Ball did. Those actually are capable of all the timings without a lot of hassle. Once the core timing is done, it's just a matter of adjusting the bits per pixel, waitvid loop, and number of PLLA cycles per scan line. I've not yet worked with the PAL template, but a quick look at it reveals the same structure. I see no reason why it wouldn't be any different.
The most common element I see is the number of bytes fetched per scan, and whether or not those are one or two bits per pixel. IMHO, writing a waitvid loop that can switch between bits per pixel on the fly will do all the screens, once the signal timing is established.
Edit: After thinking it over, I think the moto chip would be a layer not needed. It's probably smaller and enough to just specify mode data blocks, with the appropriate waitvid loop, frame, and timing data. Couple that with a few addressing schemes, and that would do all the bitmaps and character displays nicely enough. Sprites are likely a one off, for each machine.
After thinking this over, the Apple and Vic20 would be great targets for the 6502 core. Both had small memory configurations that would fit in the HUB. Early Apple machines were 4 - 48K, with a fair amount of older stuff able to run. The VIC had what 4K? The key to both of those is no sprites, and simple sounds. The VIC has some timing and more complexity in it's video memory mapping, but the Apple didn't. Fixed pages, no screen sync, no RTC, no nothing.... perfect!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 5/12/2010 4:37:56 AM GMT
But the magic is in how each console and computer generated a composite NTSC signal. Each pixel color value is needs to be translated to a luminance, color phase and color intensity. The challenge was using the smallest number of bits to generate the largest number of colors via the least complex circuitry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
I think it quite fair to say that TV should be the choice because of pin usage. I don't think we should bother with the 6845 register emulation as it is just another layer. IIRC there was a later 6545 that was also used. We need to understand each set of video usage and then try to map that to a TV (composite video) emulation. We will have to do some form of conversion for the color bits to conform to what the prop requires.
Do we need read access to the screen layout ????
Can we get away with using 2 pins for the TV ???? It's certainly an idea. I do not yet understand the color generation part of the TV generation (1pinTV is B&W).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
FWIW in case of the Colour Genie I have to bother with it for 2 reasons: a) the cursor address (and shape) is defined by reads/writes via I/O ports to the CRTC registers. b) The frame base address is written to the corresponding CRTC registers and I have to do page flipping etc. by copying XMM to my (smaller) frame buffer. The addressable range for video was 16KB while my frame buffer is 4KB.
As always: it depends. Some machines have fixed layout, others (especially those with a CRTC) are variable. The 6845 registers for the layout are write-only, though, so the software must know what was configured.
I have no idea. The outputs for TV allow for 8 different levels (ignoring the TV audio for now), and I seem to remember that the colour information (chroma) sits on top of the luminance signal. The link describing the structure of PAL and NTSC signals should perhaps tell if you can generate a colour video signal with just 2 bits = 4 levels!?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
The 1pinTV text driver uses CTRB in DUTY mode to generate three output levels: sync (CTRB off, video out 0), black (CTRB on, video out 0), white (video out 1). The Propeller video generator has three output modes: VGA (which outputs 8 bits), composite/S-Video (3 pin luma DAC with PSK color either added to the luma or on a separate pin) and broadcast (modulated composite). It is possible to use both the VGA and the composite modes to generate TV graphics. With VGA mode extra work is required to generate color from a simple luma output, but with composite you are locked to using 16x colorburst (IIRC) for FRQA.
But let me think whether 2 bits + DUTY is enough DAC to generate color. For color you need -40IRE (sync), -20IRE & +20IRE (burst), and 0IRE(black) to generate a normal frame. That's 4 levels already, or 2 bits. Hmmm... if the PSK color is on a separate pin, and you set your DUTY so 1pinTV white is more grey, then you should be able to get 16 colors, maybe some dark colors with PSK color on black. So yes, it might be possible.
But really, 3 pins gets you the normal Propeller TV output.
There's three steps for the emulation.
1. Having the emulated application store the graphics data in a way the video driver cog(s) can use. This could be the native frame buffer or video registers, but might mean some pre-processing.
2. Taking that native graphics data and translating it into a form which the video driver needs. For frame buffers this might be a color translation, but for tile+sprite GPUs this might mean creating the pixel data for each line.
3. Finally, that pixel data is sent to the Propeller video generator along with the sync pulses and colorburst required by the TV.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
Now, I presume with 2 pins, we would have to use the composite mode and not the VGA mode. I do not know enough about the video counter logic and also exactly how the color burst is generated. If it were possible to get 16 colors with just 2 pins then it would certainly be worth the work (for me at least). I just don't know how to go about it.
Re Emulation:
( I never wrote or played games on the old computers. I used Apple ][noparse][[/noparse], Apple //e and Apple /// with Microsoft Z80 cards for development of an Apple card to do mainframe communications. )
I expect that we may have to hold 2 copies of the screen as suggested. One is in the original format for the actual game and the other is just the actual data being displayed by the prop hardware. This means that the game will have the screen data in SRAM and the prop screen data will be in hub.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
The 6502 + Prop circuit I've got sitting here partially built has me thinking about variations on the multi-prop boards out there now. It's nothing new, just a WIP to chip away at building another one like Dennis did. One of the ideas he used on it got me thinking though.
Is it possible for multiple props to share a 16 bit address space? Maybe just two Propellers? He used buffer chips to reduce the number of pins required for RAM / Prop communication to less pins. In his circuit, he clocks the 6502, using it for addressing by feeding it instructions. Maybe it's possible to just do full on addressing and data reads and writes to the shared RAM that way. Props run well at 100Mhz. Seems to me, that's possible at the speeds needed to deal with older machine emulation.
Is there some combination of buffer chips that could collect address and data values, latch them, then operate the RAMs on less pins overall? And is there a kind of RAM that would permit this to occur with more than one Prop?
Since we are talking hardware, maybe it makes sense to do an emulation board, where there is a shared RAM to hold the program and data, with more than one Prop reading, writing to it, while each prop offers the I/O, SD, video, etc... I'm just tossing the idea out there, wondering if a different set of choices might make emulation more possible? At the least, get an address space that's large enough to do some of the better, but still slow machines.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 5/13/2010 4:20:26 AM GMT
I looked at the asm for the 6502.
It would have been fun to program those old chips!
About video: I just wish you could find cheap, small 4:3
VGA monitors, all you can find are 16:9 models.
I buy old small ones when I see them on ebay at a low price.
Composite is starting to seem very last century so I don't
really use it that much... I do have some nice composite monitors I
picked up that were made for car DVD players.
IMHO, the better display and capture devices really get the most out of the old signals. Monochrome stuff is monitor quality, and at a pretty high resolution too. Color is lacking that quality, but it's close enough to enjoy and read. Displays back in the day were not anywhere near as good as what we get now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
composite video I kept thinking of the scenes from the old movie
"Contact" where they were picking up video that aliens copied
from an early 1930's German broadcast and sent back toward
the Earth from light years away
The video from the prop looked just like the scene from
the movie where they were looking at the signal waveform.
The output from the prop looked pretty much the same on my scope.
Sorry for getting so far off-topic.
Set the Video Generator up for baseband with color added to luma, and CTRB for DUTY on the same pin (must be pin 2,3,5,6...)
sync: DUTY = 0, Video out = $00
burst: DUTY = X, Video out = color $88
black: DUTY = Y, Video out = $00
active: DUTY = Y, Video out = %xxxxyzzz
xxxx = color (0-15)
y = color enable
zzz = %000 black/color, %111=white/reverse color
sync and black are the same idea as 1pinTV: use duty to push video out = 0 above the sync value to produce black. Color is more interesting as the output will PSK between the DUTY level and high. For normal TV output burst alternates between -20IRE and 20IRE, where -40IRE is sync, 0 IRE is black and 100IRE is white. The AGC (Automatic Gain Correction) circuit in the TV uses the sync to black transition to scale the B&W intensity and the colorburst to scale the color saturation. The question is whether we can abuse this, and if so, by how much. There's a couple of different options.
The first is to make X=0 and Y=50%. This keeps the burst centered on the black level so should be compatible with the majority of AGC circuits. However, it means white will be a very dim grey and the colors will also be very dim.
The second option is to make X=40/140 and Y=40/140. This pushes the burst DC level way above black, but keeps white white and the colors well saturated.
The third option is to play with the two DUTY values to find something which works and produces the desired output.
2010-05-14 edit I forgot the color circuit is luma+/-1 which means the lsb doesn't change. Tweaked the pins and the white value to compensate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
Post Edited (ericball) : 5/14/2010 12:54:01 PM GMT
I am not quite sure I understand how to output the colorburst, etc. Do you mean change the waitvid to WAITVID $8800,0 or WAITVID $FF88,0 (defining x8800 as $8800) and changing the CTRB Duty as appropriate?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz