ClausB
-
Content Count
2,090 -
Joined
-
Last visited
Posts posted by ClausB
-
-
Is someone actually building this circuit now? Sounds like a very interesting way to add 80 column support with 640 hoz res. It can overlay any of the Atari Graphics modes including the GTIA modes, like the 16 color mode. Will be keeping an eye on this one.I'm thinking about building it this winter, but Bob has been pretty quiet lately - I suspect he's already working on something better.
BTW, the design I posted above is easily expandable by adding FRAMs in parallel to increase bit depth. 2 FRAMs would give 640 pixels of 4 gray levels, or 160 pixels of 256 colors. 4 FRAMs would give 640 by 16 grays or 160 by 65,536 colors!
-
With 3-bits of color, using "interlaced DL" RGB in gr.8, I was able to get 40+ "apparently solid" artifacted colors.Please explain.
-
It just occurred to me that the hi-res, monochrome, 640-horizontal-pixel mode could also become a new color mode through artifacting. We all know that the 320-pixel mode creates artifact color in the composite video signal: 2 bits per color clock gives you 4 possible colors: black, white, red, and blue. With 4 bits per color clock, we can get 16 possible colors: black, 2 grays, white, and 12 various colors. In fact we get the same 16 colors that the Apple II had on its lo-res 40x48 graphics mode, because it generated colors in exactly the same way. Only we can do it at much higher resolution, 160x192.
The only change to the LEM circuit would be an option to feed our enhanced video signal into the composite chroma and composite video channels, in addition to composite luma. As before, this could all be overlaid onto any Atari graphics mode, providing up to 64 colors at 160x192. Would that be useful?
-
Here's a block diagram of what I plan. The gate symbols represent discrete logic. The OSS cart already has the register, EPROM, and RAM/ROM switch logic. I would add the FRAM, oscillator, and video amp, plus some firmware.
Thanks to Rybags for the name!
-
All this extra ram your'e sticking in....is that purely for graphics oriented tasks or is that split betw. CPU and Antic Access....also, will you be able to code more complex DLI routines (as Antic will have it's own memory)....Additionally as Antic will have memory as well, will any extension to the typical graphics resolutions be possinle i.e beyond 300x192In the simple circuit I plan, the FRAM will be write-only with respect to the CPU. It will run in read mode only during video generation, independent of ANTIC. Others may wish to implement more sophisticated circuitry which might also provide CPU read access to the FRAM. Then one could even take advantage of the non-volatile feature of the FRAM.
I plan to overlay the FRAM video onto the ANTIC/GTIA video, providing many possible combination graphics modes, up to 640 pixels horizontal.
-
Do you have the FRAMs yet? Where is a good source? Which ones will you use?No. The only source I've found for the FM25256B is onlinecomponents.com at $4.70 each. I would have to order 8 to make minimum order, or get some other stuff.
Why not switch using the R/W signal?Because in read mode, the FRAM will continually shift out bits for 192 scan lines independently of the system bus, so R/-W would be changing during that time.
I don't think its possible it will work on a cartridge or through an expansion, this has to be wired directly onto the Ataris' motherboard to work.The only signal I need that is not on the cart slot is composite luma, which I can get from the monitor connector.
-
Why not just reverse engineer an antic chip and give it more capability (like it's own mem. and interlacing/higher res etc)Thanks, Carmel, for the fun diversion. Don't let nasty posts put you off!
Back to the FRAM idea: I'm considering building a simple proof-of-concept circuit based on an old OSS cart which already has a 4-bit register mapped to $D5xx. I'll keep the bit that switches between RAM and ROM but I'll reassign the other bits as:
1) switch between 14 MHz clock (for reading) and $D5xx strobe clock (for writing)
2) FRAM -CS
3) video mode
It will have one 256Kb FRAM and two modes: 640 monochrome and 320 4-lum. The 14.3 MHz clock will be a simple RC oscillator with TTL gates, synchronized to the 1.79 MHz bus clock. Should be easy to build. I'll draw it up sometime and post it. I'll likely wait until winter to build it, since Michigan summers are too short to spend in the lab!
-
Why not just reverse engineer an antic chip and give it more capability (like it's own mem. and interlacing/higher res etc)Because it's way beyond our capabilities. That would be great if we could do it - but we can't. Someone(s) out there has the knowledge and hardware to do it. If she were just an Atari Nut like we are...
I beg to differ. I think that the know how in this forum is far and beyond than what's needed for a full reverse engineering, recreation and enhancement of the full A8 chipset and hardware. It hasn't been done yet for several reasons. Mainly because it's a lot of work, and this is just a hobby for most of us. I can bet it will eventually be done.
Yes, it's been done for the Amiga:
http://www.amiga.org/modules/newbb/viewtop...988&forum=8
and for the Apple II (just Google "Apple FPGA" and pick one).
I have programmed FPGAs in LabView but I think that would be too inefficient for a project like this. Anybody got a copy of "Verilog for Dummies" to lend me?
-
I don't think Antic/GTIA even do the 262.5 lines/frame.Isn't it 262 or 312 (PAL)?
I agree. AFAIK, NTSC has 227.5 color clocks by 262.5 lines per field (half a frame). ANTIC/GTIA does 228 color clocks by 262 lines. No interlacing provided.
Has anyone ever hacked an Atari to do NTSC or PAL interlacing? Is it even possible? Isn't the sync generation hard-coded into the ICs?
Could we feed ANTIC digital output(s) into a FRAM and feed video from the FRAM? Swap back and forth each frame? Heck, you could do 480p that way! You could do 1080p that way... sort of...That's another interesting idea, Bob, resampling the AN0-2 signals. By modifying the sync commands and playing it all back to GTIA, could you generate a true interlaced or progressive scan signal?
-
The feature I like is the possibility of tweaking the sync so we can drive a component input with 480i.An FRAM could generate any sync pattern you like, but what about ANTIC's sync signals? Can they be changed? Doesn't it always give 262 lines per frame? 480i needs 262.5, no?
-
80 columns would be a great addition but what monitor would you use? Quality monochrome 15KHz monitors are non-existent these days.A modern EDTV or HDTV should do well with an S-video connection, no? Mine does anyway.
It seems like we're getting up against a CPU limitation when we move into 640 x 192 mode. That's over 120,000 bits per screen. How long is it going to take to load a FRAM?I've already posted timing estimates above.
Or, would ACE-80-2 just turn off ANTIC?If you were doing boring old 80-col text stuff then Antic would probably not be used. Although there's always the option to just have a low-demand graphics mode running like GR. 5 to provide background attributes....Yes, a lo-res ANTIC color mode behind the hi-res text would let the CPU run at nearly full speed.
-
-
One issue is if someone was going to put an effort to improve the graphics, would there be people willing to make software to take advantage of it? We are not even sure this Videoboard XE is gonna go anywhere at this point.However people like myself wanted to make a game with higher hardware requirements, we will just develop it on the PC.
Absolutely right! It's fun to speculatively and cooperatively design this sort of thing but, seriously, who's going to use it? Even if it gets popular on this forum, that's maybe a hundred users at best. While I've been posting away here, I've also been wondering, "Why didn't we think of these ideas 25 years ago?"
On the other hand, if we had a killer app or game to make use of it, it might be worth the effort. That would be another reason to put it into a cartridge, so you could include the app.
One of my thoughts has been an upgrade to ACE-80. Certainly not a killer app, but the 640-pixel mode would give a clearer 80-column display. Also, keeping the bitmap in FRAM instead of Atari RAM would free up more memory for the other apps. Those were the two major shortcomings of ACE-80.
-
an unknown board on the top. Not sure what it's supposed to do, but it has a potentiometer attached to it.That's the CPU board. It also has the ANTIC and CTIA ICs, the ground-breaking graphics chips of their day.
Notice that it only has one connector for the cart slot, so chances are this board is for a 400, not a 800. Can anybody tell me if a cart would plug directly into the connector, or am I missing parts?It's an 800 motherboard, just with the right cartridge connector removed.
Any "Left" cartridge will plug into the remaining connector, but you'll have trouble plugging an Atari cart into it because you're missing the plastic piece that opens the cartridge door. You'll have to stick something sharp into the bottom of the cart to open the door and expose the "fingers", then plug it into the connector label side forward. Or, to match the rest of your system, take the cartridge PCB out of its case and plug it in (ICs to the rear!).
-
I would say that you might want two or more FRAMs rather than trying to write only during VBLANK. You could WRITE to one while the other was in READ mode for video.Good idea.
I had though of using multiple FRAMs, not like that, but rather 2 or 4 wired in parallel. That way, you could write up to 4 bits at a time. Also, The 160-pixel 16-grays mode would be easier to implement - just read out the 4 bits at 3.58 MHz. The higher res modes would need a shift register and faster clocks.
The feature I like is the possibility of tweaking the sync so we can drive a component input with 480i.So, do you propose dedicating one FRAM to sync pulse generation?
-
Any pictures? Inside and out?
-
Oh, boy... Yes, it would work fine without ANTIC, although it would offload a lot of work onto the software. (a good thing in your book, right?) You can just sense the beginning of a frame from the composite sync - no need for a DLI.Since the Ramtron FRAM uses the SPI to start the readout, software must do it. So, to trigger the readout repeatably, a DLI routine that writes to WSYNC before starting the readout is a simple way to start the video at exactly the same time each frame. How would you sense composite sync in software?
You can capture 14mhz from the phase02 signal using a PLL.Yes, the x8 clock multiplier circuit would most likely have a PLL.
I don't think an address clock in a CPLD would be that big of a deal (about 18 divide by 2 registers?). If you set up properly, you can read SRAM during NOT phase02 for the video circuits and write (or read) SRAM during phase02 for the CPU on every clock cycle. I wouldn't even bother decoding anything - as you said, 'let the software figure it out!'. Just run the SRAM in sync with ANTIC for the whole frame. With a 512K SRAM you don't even have to use a shift register for different data depths - clock out 8 bits on every cycle and throw away any you don't need. (this is going to be lots of overhead if you're trying to do an 80 column display! you may want to make an exception if you're doing 80 columns)The cartridge port can do all this but the PBI might be a better choice - maybe allow either?
Interesting idea about interleaving video and CPU accesses to RAM - sounds alot like the Apple II, no? These are all good ideas for a CPLD-based circuit. If someone out there has the resources to produce a CPLD- or FPGA-based design and is willing to help, then we should try it. A simpler LSTTL or PAL circuit using the serial FRAM is about as much as I can tackle on my own. In my book (as you put it), one should use just enough hardware to enable a function and then employ software to make the most of it. But the great thing about these forums is that we can cooperate and come up with a good design by combining our varied skill sets.
-
If you want to use the cartridge port, you'll have to multiply 1.78MHz by 8 as that's the only clock signal you'll find on the cartridge port.Yes, of course, you are right. thanks for the correction.
BTW why send 1 bit at a time. If you use three bytes, two for the address and one for the data that is to be transferred, you should be able to send 8 bits at a time.The Ramtron FRAM device has a serial interface, which is ideal for shifting out video bits, but no so much for writing data to it. For writing, I envision wiring D7 to the SI pin and using the decoded $D5xx strobe signal to clock the single bit in. So, each 6502 sequence ASL A, STA $D5xx, can write one bit and takes 6 cycles. Including overhead, I estimate about 0.25 Mbps write speed (see above for more timing estimates). If this serial write speed is unacceptably slow, then we should add a parallel-to-serial shift register plus clocking logic to the design. IMO, once we add such hardware, we lose the advantage of the serial RAM, and we might as well go back to the standard SRAM with external address counters.
-
Wouldn't it be easier to just write to it by having either:- a "window" that gets mapped to, say $D580-D5FF
- or have 2 bytes controlling the address, then a third which you write the data to.
Another possible spanner re snooping Antic accesses - the cartidge port doesn't receive the full data bus - remember only 16K addressing is possible.
Yes, it would be easier for the software to do that. But the hardware, IMO, would be too large. Lots of 74LS ICs or a complex FPGA. Check the Ramtron link above and look at the tiny SPI. It works just like you said, only serially. Send it 2 bytes of address and 1 or more bytes of write data, 1 bit at a time. During video readout, it would stream out bits at 14 MHz, all in parallel with, but not connected to, ANTIC. There is no snooping. The only trick is to synchronize the 14.32 MHz clock with ANTIC's 3.58 MHz clock. I'm thinking of using a 4x clock multiplier chip to generate the former from the latter, guaranteeing synchrony.
I'm sorry if I didn't explain this idea very well. I hope you can piece it together from these posts. When I get more time, I'll post a diagram.
-
Like I said, refresh accesses put a spanner in the works, but incorporating some clever logic would probably sort that problem out.The clever logic is in the DLIs. For 192 scan lines, only read access for the video generation is allowed. During the other 70 blank scan lines (more for PAL), write access from the CPU is allowed.
If there was a kind of RAM shadowing where it mimiced Antic's accesses to a degree, DList and PMG accesses probably wouldn't be too much drama since they are (in a sensible situation) always different to that of the screen, and you could just store null values there.To accomplish that, wouldn't it be best to have a kind of "transparent" mode where say pixel values of "0000" just tell the device to pass the luma through unmodified.
Yes, any zero pixel would be transparent. Non-zero pixels would add their luma values to the video.
This FRAM device would not be mapped into the 6502 address space. It has an SPI interface with its own address register. For hardware simplicity, the CPU would write one bit into it at a time by writing to the cart control register at $D5xx. That is fairly slow, about 0.25 Mbps, requiring about 1/2 second to draw the entire screen (if the video generation is temporarily disabled - almost 2 seconds if it is left on).
However, fast effects are possible. To scroll the display, the CPU simply resets the FRAM read address to a new value each frame. An 80-column display could scroll up instantly and then draw a new line of text in about 1/12 second. A general graphics app could update small regions of the display more quickly because the FRAM write address is also resettable.
-
Probably work best if it had the smarts to be able to leave the signal alone in the offscreen area...We'd probably want programmable V-Height? Would be helpful so that the Atari would know when it's safe to be able to write to the RAM without access conflicts.
The "smarts" would be in the software, which would know what RAM addresses overlay the valid display, and would put zeroes into the RAM elsewhere. A DLI at the top of the display would enable the video readout, and another DLI at the bottom would disable reading and enable writing to prevent access conflicts. Since this could be in a cartridge, it could include firmware subroutines to do all the messy work.
What about adding the 32KB of RAM and then accessing it at the same as ANTIC and using part of the address?You have some fine ideas there, and we have discussed similar schemes earlier in this thread. They all require wiring into the motherboard or CPU board. If we leave ANTIC alone, then the whole thing could fit into a cartridge and a video cable, and many more users would try it.
-
No reason you should drop it... if it were simple, someone would have done it already!I've been kicking these ideas around in the back of my head for some time but yesterday it hit me. Don't bother with ANTIC at all but rather just clock the enhanced luma bits out of SRAM every cycle. There are 228 cycles (color clocks) every scan line and 262 lines per frame, about 60K cycles per frame. About half of those cycles are during H- and V-blank, but so what? Just keep zeroes in those parts of RAM. We would need binary counters to supply the SRAM read addresses, and they could be reset each frame by a DLI to synchronize them with the ANTIC/GTIA display. The enhanced luma data from the 32K-byte SRAM, 4 bits per color clock, could be summed into the GTIA video, so it would overlay. There could be 3 modes: 640 horizontal monochrome pixels; 320 4-gray-level pixels; or 160 16-gray-level pixels. That last mode, overlaid on the 16-color GTIA mode, would give a true 256-color display. The first mode would allow a clear 80-column display.
That's still a big circuit. It would be great to have a RAM with the address counters built in. VRAM was sort of like that but AFAIK it's not available anymore. Serial RAM is like that but it's too small. In searching the Web, I found this $5 serial NVRAM:
http://www.ramtron.com/products/nonvolatil...duct.aspx?id=13
We don't need the NV aspect, but it runs as fast as we need if we clock the data out at 14.32 MHz. The CPU could write the data 1 bit at a time and then start a continuous high-speed read for display.
I think the cartridge connector has all the signals we need except for composite luminance, which could be wired over from the monitor connector. The hardware should be simple enough for me to build - the complexity is in the software, just where I like it.
Any thoughts?
-
Beyond him, my dad, who figured out how to hardware hack the Atari computer, and figured out on his own how to hack cartridge games.I believe there were many more anonymous crackers, like the Doctor's Dad, than egomaniacal ones. It was a challenging thing to do, and you could still impress your local club buddies without an obnoxious intro screen.
-
As far as making it require more software to save hardware complexity.. pfft.. Thats whats wrong with 90% of the atari expansions out there...OK. You originally asked for suggestions and that's what I offered. I did not mean to offend. Good luck with it.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
video upgrade?
in Atari 8-Bit Computers
Posted
We kicked around the idea of interlacing or generating component video at higher vertical resolution but then it can't overlay the standard Atari video.
Any volunteers?