video upgrade?

[candle]

didn't i mention that vbxe2 production run will start at end of april?

but! this is not the reason one should abadon ones project! if fit doesn't collide with vbxe (and if it will stay external it wont) then it has great learining advantages over using already made board

we (electron and i) are planning some basic sdk for development of vbxe cores (verilog, vhdl perhaps) for those who would like to learn how to write their own video modes and core extensions

but even if not so advanturous to write own hdl code english programmers manual will be provided

 

bottom line is - if this project ends up with having running prototype, or proof of concept - we all learn something, and this is most certainly NOT waste of time

[+bob1200xl]

...making something a little less invasive?

 

 

Bob

 

 

 

Well, so why am I wasting my time then?

[ClausB]

I am planning a few experiments before drawing up a schematic:

 

1) Work out a good, small TTL-to-video summing circuit. I plan to start with the old OSS cart and connect one of the flip-flop outputs to the luma signal on the DIN connector, through a diode and resistor. Then write a little routine to turn the bit on and off in sync with the ANTIC display and see how the summed video looks. It will be very lo-res, about 8 horizontal pixels, but enough to prove the circuit.

 

2) Try a simple 14 MHz clock circuit that synchs to the 1.8 MHz clock on the cart connector. Then feed it through the video summer to check the summer's frequency response. I'll build it with DIPs on a perf board wired to the OSS cart.

 

3) Study the write cycle timing of the signals available at the cart connector.

Well, Winter just returned and granted me a reprieve, so I took the time and did experiment #1. I put a 150 ohm resistor and a signal diode in series between the 74LS175 output and the TV's composite video input, and it works! See the photo (sorry for the bad photo but I had to angle down to avoid reflections). The text shows the loop that is running. The lighter-colored blocks and lines show when the LS175 flip-flop output is high (turned on by STA $D504 and off by STA $D500). They are skewed and stretched by ANTIC DMA timing, but that does not matter for this experiment, which just shows that the summing works. I tried several resistor values. Smaller ones made brighter blocks and larger ones made dimmer blocks, as you might expect.

[ClausB]

More progress: Added an 8-bit shift register to capture the SRAM output. Have not yet added a faster clock, so pixels shift out at 1.8 MHz, giving only 80 horizontal pixel resolution, i.e. 2 color clock wide pixels. See the photo: Diagonal lines on a GR.8 screen. Identical lines were drawn in two banks of the SRAM. One bank goes to the shift register in the first half of the machine cycle; the other bank goes to ANTIC during the last half. The darker lines are ANTIC's and they're delayed about 8 color clocks from the brighter lines from the shift register. The crossing line was drawn only in ANTIC's bank, just to prove the banks are different.

[+bob1200xl]

That's awesome!

 

At some point, can we see a block diagram of what you've done?

 

Bob

 

 

More progress: Added an 8-bit shift register to capture the SRAM output. Have not yet added a faster clock, so pixels shift out at 1.8 MHz, giving only 80 horizontal pixel resolution, i.e. 2 color clock wide pixels. See the photo: Diagonal lines on a GR.8 screen. Identical lines were drawn in two banks of the SRAM. One bank goes to the shift register in the first half of the machine cycle; the other bank goes to ANTIC during the last half. The darker lines are ANTIC's and they're delayed about 8 color clocks from the brighter lines from the shift register. The crossing line was drawn only in ANTIC's bank, just to prove the banks are different.

[ClausB]

At some point, can we see a block diagram of what you've done?

Sure. This is what I envision for Stage I, which has two banks, one for ANTIC and one for enhanced luma. It will have an 8-bit shift register, a 7.2 MHz clock, and up to 3 modes: 80 horizontal pixels of 16 brightness levels; 160 pixels of 4 levels; 320 pixels of 2 levels. Of course, these all overlay the regular ANTIC/GTIA display. The first mode is like an extra GR.9 mode. When overlaid on a GR.11 screen, 256 simultaneous colors would be available, without DLIs. The last mode is like an extra GR.8 mode.

 

Stage II would use three banks, a 14.3 MHz clock, and a 16-bit shift register. Possible modes are: 160 horizontal pixels of 16 brightness levels; 320 pixels of 4 levels; 640 pixels of 2 levels. The last mode could provide clear 80-column text with background colors provided by ANTIC/GTIA.

 

Stage III could use all four banks and a 24-bit shift register, if the Atari data bus can be switched that fast. Among its modes could be 160 horizontal pixels of 64 RGB-like colors (2 bits per R, G, and B, encoded into NTSC).

 

I hope to finish the Stage I prototype with discrete logic. Stage II might fit into a small CPLD. What I have so far is only 1/4 of Stage I, as only 2 bits per byte of SRAM are displayed, and the clock is only 1.8 MHz, but it proves the concept of time-multiplexing the data bus during DMA.

Edited April 9, 2009 by ClausB

[ClausB]

The photo above might be interesting from a technical point of view, but it's not at all pretty. Here is a preview of the enhanced luma overlaid with GR.11 color bars. Pretty?

[Rybags]

Is this still cart based, or is it hanging off the PBI?

[+bob1200xl]

Pretty amazing...

 

So, how do you sync the SRAM with the video?

 

What is your concern about the Atari buss bandwidth?

 

Is there a gate between the Atari data buss and the SRAM?

 

Bob

 

 

The photo above might be interesting from a technical point of view, but it's not at all pretty. Here is a preview of the enhanced luma overlaid with GR.11 color bars. Pretty?

[trub]

An enhanced Indus CP/M terminal is available, which utilizes the VBXE 80 column text mode.

I attach two screenshots of Turbo Pascal and Wordstar.

The green font simulates the oldstyle hardware terminal , but it can be changed if required.

 

 

[ClausB]

So, how do you sync the SRAM with the video?

It is synchronized because it is always accessed during the first half of each ANTIC DMA cycle. It is exactly repeatable so there is no jitter, but it is not precisely aligned. The previous photo shows the 8 color clock offset (due to ANTIC & GTIA processing pipeline) but it appears not to be exactly 8 - there is a slight misalignment between SRAM pixel edges and GTIA pixels. I'll try to measure it more precisely.

 

What is your concern about the Atari buss bandwidth?

 

Is there a gate between the Atari data buss and the SRAM?

I have no buffer between the SRAM and the bus. So, even though the SRAM itself is fast, I don't know whether it can drive the entire data bus quickly enough to squeeze more SRAM access cycles into one half of a machine cycle, which is about 280 ns. I think it depends on bus capacitance. I don't know how to calculate that - I would just have to experiment with it. If it becomes a problem, then a gated buffer could fix it.

[ClausB]

An enhanced Indus CP/M terminal is available, which utilizes the VBXE 80 column text mode.

7500!

[ClausB]

Is this still cart based, or is it hanging off the PBI?

Yes, it is still based on an old OSS bank-switched EPROM cart, but there is now a perf-board hanging off it. I may post a photo but MetalGuy might laugh at it.

[Rybags]

Don't worry about him... he gives everyone's project stuff insect names.

 

But aren't you taking the clock feed from somewhere too?

 

This is starting to look good and promising anyway... will be great if it resolves to a simple, low-cost addon.

[danwinslow]

I'd buy some of these.

[AB Positive]

You know I always liked the ideal of duel Antic/GTIA and did thought about something. Is it possible to do a Trio of GTIA/Antics? Have them addressed right after the other (16bytes for each Antic, 32bytes for each GTIA). Keep Antic on page $d400 and GTIA on $D000. What I thought about was having each chip do Red/Green/and Blue.

 

I'm still new to hardware hacking so pardon me if this sounds noobish but - what would assigning each primary color to a chip do for the video processing? Is it speed that it helps with or do you actually get extra power out of it.

 

Part of me wonders how any program already made could access this setup - or would one write patches into the OS for it?

[Rybags]

A GTIA for each component means 4096 possible colours instead of 256. And, much greater flexibility of colour selection.

 

512 colours available instead of 128 for most modes, also any 2 of those in hires instead of one colour at 2 luma levels.

 

Downside is that practically no software exists to run such a configuration and virtually everything out there now would need reworking.

Additionally, PM graphics wouldn't work properly either unless you store to all 3 position, size, graf registers etc.

 

Maybe some clever hardware decode/remap could sort the PMG problem out, send any store to certain registers to all 3 chips.

 

IIRC, at least one or two people have created such an upgrade... these days though it would probably be easier/cheaper to go VBXE or to ClausB's one when he gets it finalised.

[+bob1200xl]

How do you know you're in a DMA cycle? Just by address?

 

So, you force SRAM data onto the buss while ANTIC is setting up his memory access? (while PH02 is down?) The sub-50ns memories drive the buss pretty hard. Some of the slower SRAMs do not. (like 4ma or so...) You can probably get a reasonable lower limit by scoping the data buss and doubling the rise time of the slowest bit.

 

This thing looks very cool.

 

Bob

 

 

So, how do you sync the SRAM with the video?

It is synchronized because it is always accessed during the first half of each ANTIC DMA cycle. It is exactly repeatable so there is no jitter, but it is not precisely aligned. The previous photo shows the 8 color clock offset (due to ANTIC & GTIA processing pipeline) but it appears not to be exactly 8 - there is a slight misalignment between SRAM pixel edges and GTIA pixels. I'll try to measure it more precisely.

 

What is your concern about the Atari buss bandwidth?

 

Is there a gate between the Atari data buss and the SRAM?

I have no buffer between the SRAM and the bus. So, even though the SRAM itself is fast, I don't know whether it can drive the entire data bus quickly enough to squeeze more SRAM access cycles into one half of a machine cycle, which is about 280 ns. I think it depends on bus capacitance. I don't know how to calculate that - I would just have to experiment with it. If it becomes a problem, then a gated buffer could fix it.

[AtariNerd]

Looking good Claus. While being able to stick it in a cartridge case sounds attractive,technically, as well as aesthetically , I think most realize just being able to use an add-on like this is a major triumph. I personally wouldn't mind you using a connector with the adapter sitting outside/alongside the Atari itself, allowing one possibly to use it as a cartridge pass-through, for example. Though I don't know if that is tchnically possible with this set-up.

 

 

:::rechecks to see if he's really seeing what he thinks he is:::

 

VBXE is going to production...wow. Many projects get announced, but due to various reasons often get set aside to focus on other aspects of life. Huzzah to the development crew! Hmmm, might have to pick one of those up..if they can work out a way to distribute to NA. I might have to get someone to install it for me, though, if it involves soldering. Heck, I'd buy a 130XE, etc with this pre-installed if a good job was done. If you throw in a memory and a double-pokey upgrade for a reasonable charge , I'd be a happy monkey.

 

:::rubs hands together:::

Edited April 10, 2009 by AtariNerd

[ClausB]

But aren't you taking the clock feed from somewhere too?

Yes, taking the 1.8 MHz clock from the cart port.

How do you know you're in a DMA cycle? Just by address?

Yes. It requires programmer discipline (oh, no).

So, you force SRAM data onto the buss while ANTIC is setting up his memory access? (while PH02 is down?)

Exactly. Just as shown in the diagram, I nand phi2 with a bank select bit, so the SRAM does two read cycles in one machine cycle. Even during a write to SRAM, the circuit will read the SRAM during the first half. That should be no problem because the 6502 does not drive data until the second half, after phi2 goes high. Whenever the CPU reads or writes SRAM, the circuit triggers and loads the shift register and puts sparkles on the screen. That's where the programmer discipline comes in. A future version would have a disable bit to prevent sparkles.

The sub-50ns memories drive the buss pretty hard. Some of the slower SRAMs do not. (like 4ma or so...) You can probably get a reasonable lower limit by scoping the data buss and doubling the rise time of the slowest bit.

That's good to know. This SRAM is 20 ns. It's a former 80486 cache RAM. I think it's happier doing this job than running Windows! However, it might be too fast. The theoretical timing of the data transfer from SRAM to shift register is marginal, although it appears to work. I need either a slower SRAM or a faster shift register, or a more advanced timing circuit. I do plan to bring home a scope from work and check out all the critical timings.

[drac030]

VBXE is going to production...wow. Many projects get announced, but due to various reasons often get set aside to focus on other aspects of life. Huzzah to the development crew!

 

There is no "development crew", all has been done by electron.

 

Actually more than 20 units have been made, and the software is being developed. The generated display is supersharp. And the best thing is, that once you have the hardware, you don't have to change it to upgrade to a new version - it is enough to apply (i.e. flash) the new softcore and voila, you have the new version.

 

(I know, I am repeating myself a bit, but I am very enthusiastic about the VBXE)

[+bob1200xl]

Disable?? Heck, no! Sparkles is a Feature!! Kind of MicroSprites...

 

Bob

 

so cool...

 

 

 

But aren't you taking the clock feed from somewhere too?

Yes, taking the 1.8 MHz clock from the cart port.

How do you know you're in a DMA cycle? Just by address?

Yes. It requires programmer discipline (oh, no).

So, you force SRAM data onto the buss while ANTIC is setting up his memory access? (while PH02 is down?)

Exactly. Just as shown in the diagram, I nand phi2 with a bank select bit, so the SRAM does two read cycles in one machine cycle. Even during a write to SRAM, the circuit will read the SRAM during the first half. That should be no problem because the 6502 does not drive data until the second half, after phi2 goes high. Whenever the CPU reads or writes SRAM, the circuit triggers and loads the shift register and puts sparkles on the screen. That's where the programmer discipline comes in. A future version would have a disable bit to prevent sparkles.

The sub-50ns memories drive the buss pretty hard. Some of the slower SRAMs do not. (like 4ma or so...) You can probably get a reasonable lower limit by scoping the data buss and doubling the rise time of the slowest bit.

That's good to know. This SRAM is 20 ns. It's a former 80486 cache RAM. I think it's happier doing this job than running Windows! However, it might be too fast. The theoretical timing of the data transfer from SRAM to shift register is marginal, although it appears to work. I need either a slower SRAM or a faster shift register, or a more advanced timing circuit. I do plan to bring home a scope from work and check out all the critical timings.

[ClausB]

The previous photo shows the 8 color clock offset (due to ANTIC & GTIA processing pipeline) but it appears not to be exactly 8 - there is a slight misalignment between SRAM pixel edges and GTIA pixels. I'll try to measure it more precisely.

It is about 8.6 color clocks.

[ClausB]

Is this still cart based, or is it hanging off the PBI?

Yes, it is still based on an old OSS bank-switched EPROM cart, but there is now a perf-board hanging off it. I may post a photo but MetalGuy might laugh at it.

Here's the prototype. The SRAM fits the OSS EPROM socket electrically, but not so much mechanically, so I bent up its pins on one side and extended them with half a socket. The added NAND gates handle the writes and the half-cycle bank switching. The perf board holds the shift register with room for more circuitry. The clip lead routes the enhanced luma to the composite video connector.

 

The cart extender I made long ago for copying carts serves two purposes now. It raises everything out of the XL cart bay and it deselects the SRAM on bootup because the OSS cart powers up in a way the OS doesn't like. That problem is just with the prototype. The final version won't need an extender.

[+bob1200xl]

hey...

 

Did you get that off my WorkInProgress shelf? I got a buncha brainstorms that look like that!

 

wow. It looks like you use nothing but careful programming to sync the video - that's amazing. The diode just clamps the LUMA?

 

What's next?

 

Bob

 

 

 

Is this still cart based, or is it hanging off the PBI?

Yes, it is still based on an old OSS bank-switched EPROM cart, but there is now a perf-board hanging off it. I may post a photo but MetalGuy might laugh at it.

Here's the prototype. The SRAM fits the OSS EPROM socket electrically, but not so much mechanically, so I bent up its pins on one side and extended them with half a socket. The added NAND gates handle the writes and the half-cycle bank switching. The perf board holds the shift register with room for more circuitry. The clip lead routes the enhanced luma to the composite video connector.

 

The cart extender I made long ago for copying carts serves two purposes now. It raises everything out of the XL cart bay and it deselects the SRAM on bootup because the OSS cart powers up in a way the OS doesn't like. That problem is just with the prototype. The final version won't need an extender.