video upgrade?

[ClausB]

Am I turning into another Carmel?

Ouch....that was a low blow CB

Sorry. Besides, my posting average is only 1.1 per day.

[frogstar_robot]

I assume a game like Ultima would work and be suitable,and maybe a fairly static screen like in many arcade games could do, but could something like Ballblazer be pushed? Could software sprites work, or would there be considerable lag? Or is it even more complicated than that?

 

Claus can correct me if I'm wrong but I suspect this will update the screen too slowly for that. His proposed device can't help but be faster than an XEP-80 but will still be slow to update compared with the native hardware.

 

For many applications, a bit of cleverness will mitigate this. The output of the A8's chipset will still be fast as ever and Claus' device will just overlay and enhance that video. So some fast games could use this but it would take planning and design. For instance a hypothetical Yoomp! Advanced could draw/enhance the border with the cartridge but just use regular video for the tunnel. Ballblazer could be enhanced to have a higher res score/status display and so-forth. Depending on the design of the screen, overlays could be put over more frequently updated screens as well. I'm thinking of chroma/luma "zones" with normal graphics underneath virtual tinted acetates on top if you catch my drift. Or to put it another way, the device could provide slower yet more flexible version of VBI color divisions.

 

Of course, graphicians making static screens can go completely wild.

Edited August 20, 2008 by frogstar_robot

[Mathy]

Hello frogstar_robot

 

... be faster than an XEP-80 ...

The XEP80 isn't slow, the software that uses it is slooooooooooooow. Read the XEP80 stuff on my special stuff page.

 

Greetings

 

Mathy

[Rybags]

An idea...

 

Could the device somehow detect the HSync signal, and then selectively just grab what's on the data bus shortly after...

 

What I'm thinking here is that the PMG DMA could be "borrowed" - have a register that tells it to do so.

 

So, to burst load up to about 1K of data per frame, just tell the thing to snoop the bus. Put the data you want uploaded into the Player data area. Put the players offscreen.

 

Then once the upload is complete, turn the snoop funtion off and use your Players as normal.

[ClausB]

I assume a game like Ultima would work and be suitable,and maybe a fairly static screen like in many arcade games could do, but could something like Ballblazer be pushed? Could software sprites work, or would there be considerable lag? Or is it even more complicated than that?

Claus can correct me if I'm wrong but I suspect this will update the screen too slowly for that. His proposed device ... will still be slow to update compared with the native hardware.

I don't know Ultima, but BallBlazer would be too fast for the FRAM device. It could do something like the scrolling background in Blue Max, though. If we want dynamic hi-res screens, then we should build the CPLD-SRAM device instead. Even then, we're limited by the 6502's write bandwidth -- it just takes more time to write all that hi-res data to RAM.

[ClausB]

So, to burst load up to about 1K of data per frame, just tell the thing to snoop the bus. Put the data you want uploaded into the Player data area.

Cool idea. Definitely CPLD or maybe even FPGA.

[Rybags]

Or another method:

 

Just have a burst mode that when triggered, then snoops 40 or 48 bytes of data every second cycle.

 

The border space could be used - easy, just setup a Mode F (Gr. 8 ) area with the PF1/2 colours black. Trigger burst mode on each line.

Potentially you could fit over 40 lines in per frame.

 

40x40=1600 bytes, 48x40=1920 bytes

[AtariNerd]

I assume a game like Ultima would work and be suitable,and maybe a fairly static screen like in many arcade games could do, but could something like Ballblazer be pushed? Could software sprites work, or would there be considerable lag? Or is it even more complicated than that?

Claus can correct me if I'm wrong but I suspect this will update the screen too slowly for that. His proposed device ... will still be slow to update compared with the native hardware.

I don't know Ultima, but BallBlazer would be too fast for the FRAM device. It could do something like the scrolling background in Blue Max, though. If we want dynamic hi-res screens, then we should build the CPLD-SRAM device instead. Even then, we're limited by the 6502's write bandwidth -- it just takes more time to write all that hi-res data to RAM.

 

 

I've reread through the thread and think I have a better understanding of what the device you described can and can't do now, and the complexities involved in just getting that far. Wow. Better to keep it simple for the first run. If someone wants to develope it further later....

 

Ultima was a basic top-down-view tile-based CRPG in the Dungeon and Dragons style. See attachment.

 

I was always jealous of the higher number of colors available on the newer sytems. :/

Edited August 21, 2008 by AtariNerd

[mega-hz]

Hi Folks,

 

i have read this discussion about a new qraphic possibility today,

what about the idea, to use a ST-Shifter for RGB Output?

 

And another idea: a Latch, hooked to the LUM Lines of GTIA wich is decoded to an unused adress, like $D406 or $D408 ?

This Latch could be "switched" with an DLI...

 

Wolfram.

[Rybags]

The beauty and concept of the idea in progress now is that it requires no modification inside the machine (except maybe adding chroma for those that don't already have it on the monitor port).

 

But, it comes with it's own problems and compromises, e.g. there's only so much hardware you can fit into a cartridge shell.

[+bob1200xl]

Does it all have to fit inside a cartridge shell or is it just required to interface to the Atari thru the cartridge port? The only Ataris that restrict cartridge size are the 400 and 800, which we have been defeating for years, right? No reason why we couldn't have a little 65816 in there to 'load up' the FRAM using data from the 6502 in the Atari. Hopefully Claus can create a 'proof-of-concept' and then we can start bolting stuff on if we want.

 

Bob

 

 

The beauty and concept of the idea in progress now is that it requires no modification inside the machine (except maybe adding chroma for those that don't already have it on the monitor port).

 

But, it comes with it's own problems and compromises, e.g. there's only so much hardware you can fit into a cartridge shell.

[Rybags]

Yes, it's his baby.

 

I'd also prefer something that goes a bit further as you've described but I'd say for a proof of concept that a minimal function unit would be the way to go.

 

Then there's the pass-through issue. I only see it as an issue so far as retaining the ability to use language carts like Basic XL/XE and Mac-65.

Non-banked languages could always just be run from RAM anyway.

[+bob1200xl]

Yes, if we can just get anything useful on the screen, the rest is a done deal.

 

We should be able to pass-thru any cart, actually, without using the RAM under the cart. (or, without keeping anyone else from using it - may have our 'own' RAM in there...)

 

Bob

 

 

Yes, it's his baby.

 

I'd also prefer something that goes a bit further as you've described but I'd say for a proof of concept that a minimal function unit would be the way to go.

 

Then there's the pass-through issue. I only see it as an issue so far as retaining the ability to use language carts like Basic XL/XE and Mac-65.

Non-banked languages could always just be run from RAM anyway.

[ClausB]

Yes, it's his baby.

I hope I don't appear possesive about this thing. I know that many of you have contributed great ideas toward it. And my ideas sprang from Bob's original posts and your discussions long before I ever chimed in. It's really been a group effort.

 

And it should stay that way. I don't want to hold anyone else back from building something different. I doubt I'll have enough time before winter to do much more than the 1st experiment I outlined before. It has also become apparent from your comments that the FRAM design will be too limiting to support much exciting software development. As you mention, it might still be useful for proving the concepts. But let's keep discussing improvements. And Bob, maybe it's time for those CPLD tutorials?

[peteym5]

I just say keep it simple for the first series of development and tests. One problem with Videoboard XE is that they want to do all these things with it and they still have not got around to making it global. Your FRAM device overlaying the Atari screen is a good ideal and easier to put together. Maybe later you can consider doing other things like a PBI/ECI device, internal upgrade, more memory, dual FRAMS.

 

One thing I wonder about is what would give the best speed, a cartridge or a PBI/ECI device, which is what many of us will look for in software development.

[2600Lives]

I dunno if this has been said in the thread (sorry, don't have the time to read the whole thing), but there is a guy on ebay that sells custom made S-Video cables for the Atari comps (and for the C-64 as well). They're pretty cheap, and I know a guy that has one for his Commodore, and he says it's NICE. Just do a search on ebay. He's usually got some in stock.

[Mathy]

Hello Peteym5

 

One problem with Videoboard XE is that they want to do all these things with it and they still have not got around to making it global.

 

The SIO2USB took 3 years to develope. Maybe even longer. What's the problem with that?

 

If it takes a bit longer to get a product to "market", that shouldn't be a problem. We're in 2008 now. Not every piece of hardware needs to be simple in design. I'm interested in a device that will bring 640 pixels horizontal to the 8 bit Atari. If you know my site, you know I've been wanting a device like this forever. But if the product is to slow, it's not worth my money. If the Video Board XE is compatible to existing Atari 8 bit stuff, and if it's price isn't way off the chart, I'll buy one. If the 640 pixels device we are talking about here is simple in design just because somebody says it needs to be simple in design and if it's to slow in my eyes, I'm not gonna buy it. Period.

 

Greetings

 

Mathy

[ataridano]

The SIO2USB took 3 years to develope. Maybe even longer. What's the problem with that?

 

If it takes a bit longer to get a product to "market", that shouldn't be a problem. We're in 2008 now. Not every piece of hardware needs to be simple in design. I'm interested in a device that will bring 640 pixels horizontal to the 8 bit Atari. If you know my site, you know I've been wanting a device like this forever. But if the product is to slow, it's not worth my money. If the Video Board XE is compatible to existing Atari 8 bit stuff, and if it's price isn't way off the chart, I'll buy one. If the 640 pixels device we are talking about here is simple in design just because somebody says it needs to be simple in design and if it's to slow in my eyes, I'm not gonna buy it. Period.

 

Greetings

 

Mathy

 

Sorry Mathy, I am familiar with your site and was excited with Video Board XE when I first saw it, but I have to disagree a little bit. The problem I see with long development time is that programmers could use that time to bring us great software. Not really an issue with a storage device like SIO2USB, but with an extra video mode, that's important. I say it needs to be simple, not because I'm afraid of spending the money for something that's more complex, but because of simple numbers. The simpler it is, the less it costs. The less it costs, the more that will sell. The more that sell, the more demand there will be for software that takes advantage of it. For me, the coolest thing about the idea is that a) there is no modification needed to the internals of the Atari, and b) the video is piggybacked on the existing video system. I'd love an XEP80 or some soft of VGA based 80 column device, but I know if I had one, I'd have to either have two monitors, or constantly switch between two inputs. I think this upgrade would be worth while even if just for 80 column text, and for that reason I think slow is okay (but faster is better of course). Plus, it'd work for more than just text, so it'd be like an XEP80 plus a high(er) res graphics board, all in one!

[yorgle]

I've said it before and I'll say it again, I'd buy this item if all it did was give an 80 column display.

[+bob1200xl]

How would we go about running a tutorial on CPLDs? Should we pick a project and build it? Perhaps post a short explanation and take questions/responses in its own thread? One thread follows another?

 

How about an internal PBI controller with a CF interface as a project?

 

 

 

 

Yes, it's his baby.

I hope I don't appear possesive about this thing. I know that many of you have contributed great ideas toward it. And my ideas sprang from Bob's original posts and your discussions long before I ever chimed in. It's really been a group effort.

 

And it should stay that way. I don't want to hold anyone else back from building something different. I doubt I'll have enough time before winter to do much more than the 1st experiment I outlined before. It has also become apparent from your comments that the FRAM design will be too limiting to support much exciting software development. As you mention, it might still be useful for proving the concepts. But let's keep discussing improvements. And Bob, maybe it's time for those CPLD tutorials?

[drac030]

If the Video Board XE is compatible to existing Atari 8 bit stuff, and if it's price isn't way off the chart, I'll buy one. If the 640 pixels device we are talking about here is simple in design just because somebody says it needs to be simple in design and if it's to slow in my eyes, I'm not gonna buy it. Period.

 

By the way, electron, whom I met at the Głuchołazy meeting this year, has promised a 640-pixel mode for VBXE (with RGB quality).

[+David_P]

Would it be worthwhile to set up discussion groups and a source repository at somewhere like Source Forge for this project? Atari Age doesn't really have the tools for managing a distributed development project like this.

[frogstar_robot]

If the Video Board XE is compatible to existing Atari 8 bit stuff, and if it's price isn't way off the chart, I'll buy one. If the 640 pixels device we are talking about here is simple in design just because somebody says it needs to be simple in design and if it's to slow in my eyes, I'm not gonna buy it. Period.

 

By the way, electron, whom I met at the Głuchołazy meeting this year, has promised a 640-pixel mode for VBXE (with RGB quality).

 

VBXE also requires getting inside the unit and desoldering and resoldering on unsocketed units. We've also been hearing about VBXE for two years now. I suspect it is somewhat overengineered. Simplicity in installation is a virtue because the need to open the unit up will reduce the potential audience by half or more. It also means you don't pay to have someone else install it for you. A cart/PBI device is "plug-n-play" in a way that VBXE can never be unless redesigned.

 

Simplicity in implementation is a virtue because it establishes a base for others to hack on and in that way we find out which features are apt to be used by software devs and which are not. A simple implementation also keeps costs down and gives us the potential to have more than one source for the upgrade. I could see a rev 1 device where we learn the best ways in terms of both performance and cost to improve it. Once there is consensus on what the capabilities should be and how much we're willing to pay for them then we can have a rev 2 device that is only as fast and featureful as it needs to be.

 

I also have doubts about VBXE because it's capabilities seem to be a poor impedance match for the A8. A high bit depth hi res screen is of little use if it takes minutes to draw it. I realize the board itself is a kind of video accellerator but it still has to be fed through the A8's relatively slow buses. How is a 1.79 Mhz machine going to have the processing and IO bandwidth to fully utilize such a device? If it is as expensive as I suspect it's going to be then how many people will buy it? Unless a lot of us buy it then hardly any software will be written for it and without software why buy the hardware?

Edited September 2, 2008 by frogstar_robot

[peteym5]

There will always be hardware and software dilemma for these video devices and the choice of getting one. Many of us do acknowledge the fact that VBXE will require some work on the inside, but that also means it will much faster than going through a cartridge port. If I am not mistaken, VBXE will include its own 512k ram probably on its own bus, only problem I see there is when it has to transfer stuff from the main ram/bus that will slow up things. It may be much faster than a cartridge or ECI device.

 

It is hard to say how fast a cartridge video device will run when it has to do some sort of bank switching to transfer information from the main ram to the video memory. There are smart ways to manage it, what you have to avoid is bank switching every time you want to transfer one byte, but do complete block copies when you have one of the banks exposed.

[roland p]

A high bit depth hi res screen is of little use if it takes minutes to draw it. I realize the board itself is a kind of video accellerator but it still has to be fed through the A8's relatively slow buses. How is a 1.79 Mhz machine going to have the processing and IO bandwidth to fully utilize such a device?

If the atari only has to tell the videoboard to draw which sprite on what location, I don't see any problem.