ClausB
-
Content Count
2,090 -
Joined
-
Last visited
Posts posted by ClausB
-
-
Has anyone tried, in a game or demo, to output progressive scan video (480p) from a 2600? It would seem to be easy, just issue VSYNC every 525 scan lines instead of every 262, no?
-
Here's an explanation of the 256K XL banking method:
In 1984 I designed the 256K "Quarter-Meg" XL RAM upgrade published in BYTE for September, 1985. It used 8 banks of 32K each. In 1985, after the 128K XE came out, I redesigned the upgrade for 16 banks of 16K. Later, that design was sold as the "Rambo XL".
The XL and XE computers use Port B bits to control memory configuration. Bits 7, 1, and 0 control ROM/RAM switching. In the XE, bit 4 enables extended RAM for the CPU and bit 5 enables it for ANTIC, and bits 3 and 2 select one of four 16K banks.
In the upgrade, bit 4 enables banked RAM for the CPU and ANTIC. Banked RAM appears in place of normal RAM at addresses $4000-$7FFF. Bits 6, 5, 3, and 2 select one of sixteen 16K banks. Four of those banks mirror the normal 64K XL RAM, and four others mimic the extended XE RAM, as below.
PB Bank RAM -- ---- --- $FF none normal $83 0 mirror of normal $0000-$3FFF (page 0, stack, OS variables, DOS, etc. -- dangerous bank selection) $87 1 mirror of normal $4000-$7FFF (same address as bank area -- useless bank selection) $8B 2 mirror of normal $8000-$BFFF (usually screen RAM -- not very useful bank selection) $8F 3 mirror of normal $C000-$FFFF (RAM under OS ROM -- useful) $A3 4 extended $A7 5 extended $AB 6 extended $AF 7 extended $C3 8 extended $C7 9 extended $CB 10 extended $CF 11 extended $E3 12 XE-compatible extended $E7 13 XE-compatible extended $EB 14 XE-compatible extended $EF 15 XE-compatible extended
Now you can see why the RAM utility program does not recognize $87 because it's the same as normal RAM. You can also see why it crashes with $83 because it probably clobbers the OS, DOS, or even itself when it tries to write into that bank.
-
Summer's over...I get the hint! Although, it was 80° here today. Forecast says Summer will be over next week.
But here in Michigan we have another season between Summer and Winter. It's called FLL. That's FIRST Lego League competition season. Go Programmers!
-
It was in a Mom & Pop shop in East Lansing in 1980. I had been lusting after the Apple II, but when I saw their 800 running Star Raiders I was hooked. I learned about the 800 and 400 from their very knowledgable salesman, but Pop would not let him deal on price. When a chain store had a sale on 400s in December, I grabbed one along with Star Raiders. Happy Christmas!
The first salesman, who had become a friend by then, was bummed but he understood. As consolation, I bought a 32K RAMCRAM from him and watched over Pop's shoulder as he installed it. I was ignorant about electronics then but that really piqued my interest. The salesman friend also let me photocopy his photocopy of the Atari Hardware Manual and, later, the OS manual. I learned a lot about "Candy" and we had a blast.
Later when my friend quit, Mom & Pop hired me. We sold Ataris, Exidy Sorcerers, and Vector Graphics computers, plus software and magazines. They wouldn't let me deal either, and we ended up closing shop. But, hey, I got paid for playing Star Raiders! It was in that shop where I got my highest rank ever, Star Commander class 2, while patient customers looked on.
-
Same here. When I first saw Star Raiders on an Atari 800 in the fall of 1980, I knew I had to have one, but not for $1000.I saw Atari 800 running Star Raiders ... Next day ... I go back to store and buy the system (800, 810, 410, 850, some games)That Christmas, Atari had a promo for their cassette- and cart-based Education System. You could get an 8K 400, a 410, the cart, and some tapes for $400 or $500. But I managed to trade the Edu cart and tapes for a Star Raiders cart. Happy Christmas!
-
Basically, there is too long a path to resolve the hardware state in 35ns or less.Question: if you set up multiple FRAMs with the same starting parameters at the beginning of each video frame, (like all start at address $0000) couldn't you load/start them concurrently? No reason to load each one by itself, is there? Only the data for each memory has to be done individually? There is no protocol, per se. The CPU talks - the FRAMs better be listening.
Thanks, Bob, for the explanation.
Yes, I had intended for the multiple serial FRAM design to use them in parallel. That is, hook them all up to the same serial clock and the same select signal. Each FRAM's serial input would come from a different data bit (say D7 and D6 for a dual FRAM) and each serial output would be a different luma bit. Then they could be loaded by the CPU concurrently (2 bits at a time for a dual FRAM), using the SPI protocol.
-
Not to be greedy but...
How much faster could it be made to go? Which component limits the design to 7 MHz (besides the clock)?
-
It's a 65816 running RAM at 7.16mhz. The Atari chipset, OS ROM and cartridge all run at 1.79mhz. It doesn't seem much faster until you run the OS in RAM, or load TBXL. Then it runs about 300% faster.Cool!
Can't wait to see the design.
-
As long as the cartridge knows where he is on the display, you can use that timing to initiate video alterations to the combined display screen. Not as versitile as the DLI but it would incur no overhead to the system (other than loading the FRAM initially). This gives you back CPU time that would be spent on DLIs. And, it's much 'faster' than a DLI.I still don't get it. Maybe I'm too fixated on the present design, which connects to the cartridge port, not directly to ANTIC. But it does use DLIs to sync the enhanced video output with the ANTIC/GTIA video.
-
Sorry for redundant posts, but are there some specs about that video-enhanchment cartridge?Specs are still in flux, but presently the horizontal resolutions are 640 monochrome pixels with 2 or 4 luma levels, or 160 pixels with 16 or 256 artifact colors. Write speed estimates are about 0.25 Mbps for the FRAM design vs. about 1.5 Mbps for a SRAM/PLD design.
-
The first few times I read your post I said "HUH?".But,,, after you unravel all the spagetti... yes! You could extend DLI code into the cartridge.
That's actually a great avenue to pursue!
Bob
IF the video cartridge upgrade taps into Antic somehow...wouldit not be possible to extend antic timing for DLI's...i.e so that you can program more elaborate DLI's instead of being restricted to only a few 'cycles' for DLI programming or instead of theantic timing for DLI's being restricted to 'cycles', would it not be possible to route that aspect of antic's timing to the onboard cart. mem again so you can program more elaborate DLI routines and the only restriction is the amount of video FRAMS memoryJust a thought that's all
Sorry, I can't quite unravel it. Please explain.
-
The 5200 expansion port is not the same as the cartridge port.It has the Pokey serial i/o lines on it, as well as a small assigned window for a rom decode not normally used in the 5200.
Expansion Port: Top Bottom ----------------------------------------------- +5V DC 1 36 +5V DC Audio Out (2 port) 2 35 Not connected Ground 3 34 Ground R/W Early 4 33 Not connected Enable E0-EF 5 32 D7 D6 6 31 D5 D4 7 30 D3 D2 8 29 D1 D0 9 28 Ground IRQ 10 27 A0 Ground 11 26 A1 Serial Data In 12 25 A2 Serial In Clock 13 24 A3 Serial Out Clock 14 23 A4 Serial Data Out 15 22 A5 Audio In 16 21 A6 A14 17 20 A7 System Clock 01 18 19 A11
Has anyone figured out what A14 is doing on that Expansion Port? You do need A11 and "Enable E0-EF" to select pages $E0 thru $E7, so as not to conflict with POKEY, and you need A0 thru A7 to address within those pages, but WTH is A14 for?
-
No. It is designed for 600XL, 800XL and 1200XL. One board can fit all.ehm...the turbo board...is that for 1200XL only?Does it have a different, faster CPU? How many details can you divulge within the contest bounds?
-
25 years ago I dissected a friend's 5200 and noted how it differed from my Atari 400. I also disassembled the ROM and compared it to the 400/800 OS. I then used the info to convert the 5200 PacMan cart to run on the 400/800. From those notes I wrote this article for ANALOG magazine:http://www.atarimuseum.com/videogames/cons...nv_to_5200.html
Unfortunately, there were some typos in the published article. I sent them a clean printout and a floppy disk with the proofread article in some Atari format. They said they could not convert the disk to their typesetter so they manually retyped it and filled it full of typos. When I sent a letter to the editor with corrections and updates, they edited out the corrections!
The typos survive on the Web copies too. Here are some I noticed:
"POKEY's registers are all addressed at page $EB in the 5200 as opposed to $D2 in the 400/800." That should be page $E8, but luckily any page from $E8 through $EF will address POKEY.
"The even pots (POT0-POT6) give the horizontal positions of range from 1 to 228;" That seemingly poor English is really the start of one sentence grafted to the end of another. Between "of" and "range" should be something like "the joysticks and the odd pots give the vertical positions. The position values".
In the cartridge pinout table, pin 9 should be "-Enable 80-BF", not "Enable 80-8F", and pin 10 should be "-Enable 40-7F".
I recall their were more typos, but that's all I can find now. Has anyone else found others?
-
Would you happen to have the source code to Star Raiders to share?I have the source code to 800 Desert Falcon... I also have the sources to 800 Galaxian...Well, I can dream, can't I?
-
25 years ago I dissected a friend's 5200 and noted how it differed from my Atari 400. I also disassembled the ROM and compared it to the 400/800 OS. I then used the info to convert the 5200 PacMan cart to run on the 400/800. From those notes I wrote this article for ANALOG magazine:
http://www.atarimuseum.com/videogames/cons...nv_to_5200.html
My question to all of you is this: Which game conversions were done using the info in that article?
-
3
-
-
Well, Atari made analog joysticks for the 5200, which itself was based on A8 hardware. The analog joysticks used POKEY's pot inputs, like the paddle controllers did. IIRC, the analog joysticks had poor or no self-centering and most people agreed that they sucked.
-
Will this device work with Turbo-Basic XL?If someone can help with testing and debugging, we'll make it work. The development of this thing should be a group effort, using these forums, so as to satisfy the whole group.
-
No additional sprites but the Atari PMG would still function normally.what about the sprite capabilities?
Well, I hope to include some firmware in the disappearing ROM to support 80 columns (like ACE-80) and graphics primitives.There are no macros or programmed routines - you do it all.
The disappearing ROM would allow normal access to the 8K (either BASIC or RAM) under the cart, just like ACE-80.I suppose you could write under the cart ROM space but I don't think Claus has that in mind. -
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.Yes, it's his baby.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?
-
Cool idea. Definitely CPLD or maybe even FPGA.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. -
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.
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 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?
-
Am I turning into another Carmel?Ouch....that was a low blow CB
Sorry. Besides, my posting average is only 1.1 per day.
-
Maybe if I stay the hell off these forums, I'll have time for some experiments! Am I turning into another Carmel?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Progressive Scan on 2600?
in Atari 2600 Programming
Posted
Not through the antenna (RF) connection, but maybe through composite or S-video (from a modded 2600)? Don't EDTVs and HTDVs support 480p30 through YPbPr component inputs (for progressive-scan DVD players)? I know that the color encoding is different between NTSC (composite or S-video) and YPbPr (component) but I thought maybe the progressive scan mode might apply to both. I suppose you could feed the modded 2600 composite video to the Y component input and get 480p30, although without color.