ClausB
-
Content Count
2,090 -
Joined
-
Last visited
Posts posted by ClausB
-
-
Not so. I plan to use a technique similar to what I did with ACE-80XL. The cart ROM would switch off when not in use, allowing normal access to the underlying RAM or BASIC ROM. When in use, the cart ROM would switch on only during OS calls and then switch off before returning to BASIC or other calling app. It will work seamlessly.One issue about Atari ROM based Basic is that you will not be able to use it while the cartridge is plugged in since the cartridge will displace the Basic ROM memory.If we do cart pass-thru, it will work the same way, allowing normal access to the other cart when this ROM is off.
-
• 1999: Network cable / protocol (one-way) from a Commodore 64 to an Atari 8bit (parallel port, from C64 user port to A8 joystick port)Also did a C-64 to Atari interface. Fairly sure it used the C-64 serial port and joystick port on the Atari side.In 1984 at PDI I did a serial cable from the Atari 800 SIO to the C64 and a one-way protocol, from Atari to C64 (because, well, nothing good could ever come the other way).
-
Let's do the math. Carmel has posted 5501 times over 1478 days. That averages 3.7 posts a day. Keep it up, Carmel!
-
Would you pay $50 to $75 (non-profit) for a cartridge that connects with the video DIN cable and adds high resolution graphics modes to the Atari? Up to 640 horizontal pixels with 4 gray levels, or 160 pixels with 256 colors, could be added on top of the existing ANTIC graphics modes. Firmware to support graphics and 80-column text would be included. For more information, see the thread that is developing the idea.
-
When/if there is a final version of a schematic posted I can try to draw up a board that would fit.Thanks, Steve, for volunteering!
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.
Once those parts are proven, I will try adding the FRAM. Just got the latest (thickest?) Mouser catalog and found the FRAM there for about $6. Not sure when I can get around to these experiments, but I am spending spare time thinking about them.
Perhaps the production board could use SOICs instead of DIPs, since the FRAM is only available that way. Even the EPROM could be replaced by a SOIC EEPROM or maybe a parallel FRAM. Steve, can you do surface mount boards?
-
On the Atari 2600, a relatively simple bank-switch chip allows pixels on a hires screen to be plotted and erased faster than any other 6502-based system I know of...Each column of graphics data is stored in a different page; an access to $7F00-$7FFF will bank-switch the $1E00-$1FFF graphics data to the proper column. The ROM at $7F00-$7FFF holds the proper mask values for plotting pixels. The net effect is that pixels may be plotted in 13 cycles if the coordinates are in X,Y.
Cute, eh?
Yes, cute. See if I understand:
So, RAM banks appear at $1E00-$1EFF (not -$1FFF as you posted, because $1FFF equals $7FFF on a 6507), right?
There must also be a kernal routine to move data from RAM banks to player registers, right?
Using venetian blinds-ish technique, right? 96 pixels horizontal, right? So, 12 columns, right?
What 2600 games use this method?
-
Yes, it is interesting, isn't it? Just wish I could find more early development documents and prototypes online. I've heard that someone in this forum has other prototypes, but when I asked for photos I got nothing.I just have to say it: I love this kind of digital archaeology. Keep it up!
What could be done with the photos and info posted above to make them more presentable or accessible?I'd personally love to see it end up somewhere that others could see it (museum display, or at least online museum display). -
Well, Wozniak demonstrated the formula (RAM down low, ROM on top, I/O high middle) in 1976 with the Apple I, long before the Atari 800 or C64. It follows logically from the 6502 architecture.I think they did the right thing, and the fact that Commodore used a near identical layout on the C-64 is testament to that.
The Colleen prototypes had 4K for I/O (see here). Be glad they cut it down to 2K.But, in hindsight, maybe having only 1K used for I/O would have been better, -
Theoretically, I would say 256 bytes - one page - because 6502 software already has to deal with addresses in 8-bit units, so a one-page bank can be addressed with index registers, without shifting and masking. There's also a hardware reason: There are several holes in the Atari memory map that are exactly 256 bytes wide, like pages $D1, $D5, $D6 and $D7. Also, for a RAMdisk, 256 bytes is the size of a DD sector. So, 256 bytes is the most logical bank size.
The point is a bit moot, though, because 16K has become the standard. IIRC, Axlon started it with its RAMDISK. They chose the middle 16K of 48K because OS interrupt routines made frequent use of lower RAM and ANTIC used upper RAM for the display. I tried, in my BYTE article, to use 32K banks, but Atari finally set the standard to 16K with the 130XE.
-
A look at the RAM cards showed 4K in slot 1 and 16K in each of 2 and 3. Both sizes used the same circuit board, dated 1978. They contained standard 4K or 16K DRAM chips and had jumpers to select the size. This was unlike the later 8K and 16K cards, which used different circuit boards and selected RAM in units of 8K.Looking at the Atari 800 OS Manual and Listing, I noticed that the routine that figures out total RAM size does so by testing memory in 4K blocks. Shades of the prototype hardware?
The OS Listing shows evidence of the old prototype's memory map. There are these strange comments on page 78:
; "A" CART. ADDR'S ARE A000-BFFF (36K CONFIG. ONLY) ; ; "A" CART. ADDR'S ARE B000-BFFF (48K CONFIG. ONLY) ;
The first one gives the correct address range for the "A" (left) cart but refers to the old prototype 36K RAM size. The second one refers to the production 48K RAM size but give the wrong address range. In the 1st post, notice that the prototype left cart range was $B000-$CFFF. Maybe these comment lines were hastily edited when the memory map changed?
-
3
-
-
Atari 800 Engineering Serial 26 prototype - with original 36K RAM but modified by Atari to reflect production memory map, OS, and BASIC. See this thread.
Atari 400 plus Axlon RAM-CRAM - self-modified for 48K RAM.
Atari 800 - self-modified for 64K RAM, plus AXLON RAM-CRAM self-modified to 128K RAMDISK, plus self-made SoftCart, plus self-made EPROM burner. See here.
Atari 800XL - self-modified for "Quarter Meg" RAM, plus partial Supervideo mod. See this one.
-
Thanks. I just found the paragraph in the Hardware Manual that says that.Bitmap modes only read the data on the first scanline. -
Nice chart but here's a question: In those lo-res bitmap modes with pixels more than 1 scan line high, does ANTIC fetch the same data every scan line or does it only fetch them for the 1st line and store them in the shift register for following lines?Here's the document on timings: Antic_Timings.txt -
Yes, they did steal his $5 for a POS C128.I think my worst buys are always at yard sales. Last summer I picked up a Commodore 128 with disk drive and a bunch of floppies for like $5. I have no idea why, I never had one, and wouldn't remember how to use it even if I ever get around to plugging it in. It's pretty funky too, all yellow and dusty.You consider that a worst buy?
That was a steal. -
A hand-wired circuit might barely fit into the old OSS cart case. If this thing works and if there's enough interest and if someone with PCB layout ability volunteers, then we could make a version with SOICs that would fit into a cart case.Do you think the PCB will fit inside a normal cartridge case? -
Not all models have Chroma, though. I wish I could find out why it was deleted.
Maybe so, but I suspect it was because so many Atari users (like me) were buying Commodore monitors, which supported separate luma and chroma.According to an interview in either ANALOG Computing or ANTIC (but I guess it was ANALOG) it was left out to make room for a second sound signal. As in "dual pokey". -
Very nice. Thanks for posting. Was this once a program for the 800?Is there an ATR of this so one can run it on an Atari?
-
With an R: handler, this has the potential to be what the XEP-80 should have been.Why not use "X" like the XEP80 does and have it respond to "X:" and "X2:"?I don't know anything about XEP-80 or the R: and X: devices, but when I wrote ACE-80, I hooked it into the OS's S: and E: devices. That is how I plan to support 80-column text with the LEM. Is there anything wrong with that?
-
The cart will let the OS boot normally and the enhanced video will not be active. The disappearing ROM in the cart will hold the graphics support routines that will activate the enhanced video. A la ACE-80, the ROM will not displace your top 8K of RAM. Rather, it will load a small kernal into RAM that enables and calls the ROM when needed.I take it that if you are going to do this mod/upgrade on cartridge....you are going to program it so that it acts like a diagnostic cartridge...i.e that the cart takes over some of the P.O.S.T initialization on the A8 and not program it like a normal cart, otherwise you might have to find a way of allowing the normally programmed cart to take control of the internal gfx hardware (on the atari mobo itself) instead of the o/s telling the cart what it can and can't take control of -
Very nice. Thanks for posting. Was this once a program for the 800?
-
The FRAM is about $5. LSTTL chips, about $5. EPROM, maybe $2. Video connectors, maybe $5. PCB, maybe $20. Assembly and testing time, maybe 2 hours. Rough total, at least $50. Probably more than your Atari is worth on eBay.Could you give us a rough estimate of what the LEM would cost? -
Yes.ie take the existing Luma output from the monitor port then add the extra signal on top.
No, keep the GTIA luma too.So, effectively what you're doing is retaining the colour information, and discarding the luma except the sync pulses.
Yes, we would probably want the enhanced luma to be about equal to the existing luma value of 8. Then you could program GTIA to add smaller luma values (like 4 and 2) to get several gray levels, no?Of course, existing luma info could co-exist - I guess there are various combinations that could be used, like having the device only generating Luma levels equivalent to fractional values between 0 and 4.That would allow a huge increase in potential luma values. Although you'd probably want the thing to be capable of generating a fuller-strength signal of it's own accord to be properly useful for hires text and images.
AFAIK they are available components - tiny 8-pin SOICs. I have found one on-line source (see previous posts) but have not bought any yet. Guess I'm waiting to hear from you all how much interest there is. Maybe Bob is already experimenting?This certainly has a wide range of possibilities of combining it with various Atari 8-bit modes. Do these FRAM chips already exist or are they like available logic for those ASIC chips? -
The nice thing about this FRAM is that it can clock out its data serially all by itself. With normal RAM (SRAM or DRAM) the video circuit must constantly supply sequential addresses to read out the video data. If you use a CPLD or FPGA, then it's no big deal to put in an 18-bit counter to supply the addresses, but if you want to use just a few TTL chips, then you need a serial RAM of some kind with its own address counter. The only large serial RAM I could find online was this FRAM. Its serial output is fast enough for 640-pixel-wide video, but its serial input is limiting. A simple circuit that writes 1 bit at a time would be fairly slow (see previous posts). A faster circuit with a shift register and timing logic would again require too many TTL chips or a CPLD or FPGA. But once you commit to a CPLD or FPGA, you might as well use a standard SRAM. So, I think that the FRAM is most useful for the case of the small TTL circuit.(ClausB) Just curios as to why you use F.RAM instead of mormal RAM...or is F.RAM better suited to graphics related tasks then normal RAM
Only if you also double the output clock rate.Also, if you double the F.RAM capacity on each chip (i.e say 32k instead of 16k) will that double the horiz. gfx resolution -
I don't intend to build a PBI version just yet, but others might. As I have posted, I would like to build an experimental version from an old OSS cart I have lying around. If we do eventually make a PBI version, then any advice on compatibility with other devices would be very welcome.If it will be connected to the PBI, will it work with other PBI devices that are willing to share the PB?
Never say "can't" but it would be difficult to modify the Atari sync signals to increase the vertical resolution. The simplicity of this design comes from the fact that we are just summing the enhanced video with the standard Atari video signal which contains sync and timing for only about 200 visible scan lines. Bob posted an idea a while ago about generating new sync signals with another FRAM, and that could provide more vertical pixels.Could you please explain why "double width" can be overlaid, but "double height" can't?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Theoretical Question: Banked Memory Size
in Atari 8-Bit Computers
Posted
I've been reading about 2600 programming on the web lately. As an old 400/800 programmer, I did not know before how it was done. It's pretty impressive how much the 2600 programmers squeezed out of the minimal hardware!
Sorry it's off topic. Or is it? We 8-bit guys could learn a trick or two from Stella coders.