Urchlay
-
Content Count
1,213 -
Joined
-
Last visited
Posts posted by Urchlay
-
-
For the life of me I can't remember which memory locations I need to use in order to read data directly from a disk sector.
So ... um ... help?
Have a look at Mapping the Atari: http://www.atariarchives.org/mapping/memorymap.php
Search within the page for "DDEVIC", location 768. This is the start of the DCB (device control block). There's actually enough information there to figure it out on your own...
What language are you using? I could post a bit of code in assembly or BASIC (though BASIC would still need a small machine language routine to make the actual SIO call).
-
C64 version is missing something IMO.
The 4-player mode? Only 2 joystick ports on the 64... or was there some workaround for it? (Paddles, keyboard?)
-
Ideally the perfect setup would be the Atari 800XL with the original 800 rom in there and the 1200xl keyboard....and the 1050s of course
Hm, my ideal would be the other way around: Atari 800 with 800XL ROM and 64K (or more) RAM.
I think I like the 800 keyboard better than the 1200XL one, too...
No argument on the 1050's, so long as they've got US Doublers or some other upgrade.
-
It's also terrible for my laptop, since I specifically bought it because it's a low-power Intel chip that can run silently (ie, no fans). Pegging the CPU like that causes the fan to cut in, which is quite annoying. Also, on the GP2X and WinCE devices, doing this would kill the batteries much faster. Stella doesn't work on the just the desktop.
Yah, I was posting it as a "I've tried this, and it sucks" example, not an example to actually be followed
...although really old (0.x and 1.x) versions of Stella used to do exactly that (at least, the X11 port did)... which kept me from being able to use it on my laptop, too.
-
My worst nightmare is becoming a reality(atari vcs/2600 ,or any other classic gaming console,that use the old NTSC standard,will no longer work with modern tv's
Actually, the problem isn't that old consoles use NTSC... it's that they don't generate a *correct* NTSC signal. It's good enough to drive an old analog CRT TV, but modern TVs convert the NTSC signal into some sort of digital form (since LCDs need digital input), and the converters are less forgiving about what they'll accept as a valid signal.
Even brand new non-hi-def CRT TVs might have problems because they try to detect bad/missing signal so they can blank the screen (usually it turns blue), and the electronics that do this might be pretty picky about what's considered valid or not...
...but I don't really blame the TV manufacturers. This is a result of a design decision (to generate "almost correct" NTSC) that was made by the console maker(s) back when the console was first being designed.
You can just about always clean up the signal enough to get it working on a new TV by running it through a VCR...
You can also buy a brand-new (fairly) large screen CRT TV for under $500 that will work just fine with a 2600 (mine's a Philips, and it works just fine with an unmodified 2600, or one with a composite output mod).
-
It will never be possible to be this accurate on a system that doesn't have a real-time OS...Why not? If one's objective was long-term accuracy, the thing could be as accurate as the system's clock with logic like the following:
(code removed)
No real-time OS required.
...except that non-realtime OSes typically don't provide anywhere near that level of accuracy for the system clock. You call your hypothetical delay_seconds(1.23456), but it'll actually delay for an even number of "ticks" (1.2 or 1.25 seconds maybe).
You could do it with some hardware support, like the TSC register in the Pentium (and up), or the HPET timer on newer motherboards... but you'd be tied to one hardware platform and one OS (which may not matter to you), or you'd be writing (and debugging, and supporting) many different platform-dependent versions of the timing loop.
You could also do it by running at high priority, and instead of using a system sleep() or delay() routine, write a tight loop:
while(get_current_time() < next_frame_time) /* do nothing */;
...but that'd be really annoying for users who want to do anything else at the same time (and if someone has a cheap crappy CPU fan, it might melt the CPU). Also, how you set high priority is platform-dependent, though usually it's a simple function call... but your program might have to run as administrator/root/etc, which means you now have a moral responsibility to audit your code for security holes (yes, my brain really does work this way, I can't help it).
Also, on some OSes, the local equivalent of get_local_time() suffers from the same problem as sleep()-like calls: it'll have a granularity of some fixed fraction of a second (say, 0.05 seconds, or 0.01, or whatever), and nothing you can do will make it ever return a value that's not a multiple of that fraction of a second.
Most of this discussion came from painful experience acquired while porting z26 to Linux (and BSD)... there are ways to work around all these issues, but it's not as simple as I expected it to be.
OK, end of rant, sorry about that...
-
I arrive in my computer class the first day, and omg, we had Atari 400's! These were old tyme 400's with 8k of ram! If I remember correctly we had to plug in a memory cartridge, so we could use a disk drive, so we could load the DOS and basic language.
Ugh, the idea of being forced to type on a membrane keyboard to get a passing grade gives me the crawling horrors...
If I'd had that class, I probably would have brought my 800XL from home
Though I wish I still had a working 400. I'd park it and a small collection of cartridge games at the parents' house. I wonder if Dad could still beat me at Pac-Man or Qix...
Just imagine if there were no crappy IBM clones. IBM PC CLONES, which we still have today, have no personality. The old computers of the 80's excluding pc clones, had personality. Even the early Macs had their own personality. Just imagine if we had the same wars going on today with Atari/Commodore/Apple II.
I read somewhere that IBM actually considered licensing the Atari computer technology, when they first considered making a PC [*]. Imagine if that had happened... an Atari 800-like machine, with a proper expansion bus, detachable keyboard, and the ability to drive an RGB monitor... whatever IBM decided on was destined to become the industry standard... by the late 80s, hard disks would have been standard (I wonder if MS would have developed MS-DOS for the 6502, or if we'd have gotten something like DOS XL as the standard). We could be using PCs based on a 64-bit, 3GHz descendent of the 6502 right now (probably by AMD)
[*] This was probably just a rumor or an urban legend. I doubt they seriously considered it, since they were more interested in competing with serious business machines (CP/M based ones, in the microcomputer world back then). Still, alternate history is fun and doesn't hurt anyone...
-
I don't do Gametap either, but if it runs in Windows or Linux and can use a USB PC joystick, it'll be able to use the Stelladaptor... though it might not support the paddles or driving controller (joystick should work just fine).
-
When all else fails, RTFM
.I dunno why I forgot atarimania has 8-bit stuff... I always look there for 2600 games, should have thought of it for this.
Thanks for the link.
-
I'd like to see the arcade (NOT 2600!) Journey game re-done with KISS characters. Ace Frehley shooting lasers out of his guitar seems a lot more believable than that guy from Journey doing it...
-
I know there's a way to turn on the music during gameplay, but I can't for the life of me remember what it is... I found a site with the manual for the C=64 version of the game (press F3 to turn on the music), but I'm having trouble finding the Atari version of the manual. Anyone remember how to do this?
-
All these occur because we're not running on a real-time OS. And on top of that, even if we could be guaranteed to run/sleep at sub-millisecond accurate time, the real Atari didn't run at 60fps!
Edit: I forgot to mention, if you're using the latest version, and have access to OpenGL and vsync enabled drivers, you can turn on vertical synchronization, which syncs the OpenGL updates to the refresh rate of your monitor. If the monitor is running at 60Hz, you get a cleaner 60fps, and as a bonus, no tearing in the onscreen image.
If you really wanted to, you could probably get your monitor to run at 59.922751 Hz. That plus vsync would get you a lot closer to accurate Atari timing.
It's easy in Linux, just edit your xorg.conf, fill in values from here: http://xtiming.sourceforge.net/cgi-bin/xtiming.pl
Unfortunately, very few Linux OpenGL drivers support vsync (last I checked, neither NVidia nor ATI's closed-source drivers did, but it's been a while since I looked).
I'm sure there's some registry editing you could do in Windows to set the refresh to 59.922751 Hz instead of 60... if someone knows how, post it here.
-
I always wondered why there was no Doctor Who game for any system (at least not that I ever heard of).
No idea what the gameplay should be like, though... probably would involve lots of running down corridors, and lots of alien planets that look like badly-rendered rock quarries
Not a movie or a TV show, but it would be cool to see a game based on Larry Niven's Ringworld (no, Halo doesn't count). It'd have to be an RPG with tons of scenery and locations.
Hm, and you could probably make a great game out of Metalocalypse (AKA Deathklok)... because the 2600 is so metal!
-
I always played Spy Hunter with one joystick in hand, and the other on the floor, barefoot, with the fire button under my big toe... At one point I "borrowed" the footpedal from Mom's antique sewing machine and wired it up as a fire button. It worked great, and it turned out she didn't actually kill me after all
-
Wow, I have no idea how to rectify this problem, other than buying a new television!
Well, you could buy an old TV instead... a used one, I mean. The older the TV, the better chance it'll tolerate weirdnesses in the signal (I have a 1976 NTSC color TV that can actually display a PAL 2600 game without rolling).
On the other hand... you were talking about a composite mod. The older the TV, the less likely it is to have a composite input, so maybe I'm telling you wrong.
-
If you tie luma/chroma directly together and stick it into a composite input, you'll get some rather crappy looking composite video I believe.
I meant, connect the luma/chroma normally to the s-video luma/chroma inputs, then short the luma to the chroma, so the luma and chroma signals get mixed, and both luma and chroma appear on both inputs... would this even give a usable picture?
-
To effectively use the 320x200 resolution mode, you have to work around the artifacting. This means you have to avoid horizontal runs of even or odd pixels. Either pad single pixels with two or more blank pixels on the left and right, or have two or more in a row touching each other. The Atari's own built-in character set uses the latter technique.
Padding a single white pixel with two or more blank pixels on the left and right results in a purple or dark-green artifacted double-pixel, not a white pixel...
Two white pixels, padded with two blank pixels on the left and right, results in one double-pixel, either red or blue, depending on whether I start on an even or odd column.
The only way I'm ever able to see a single pixel of any color is to switch to s-video (which kills all artifacting effects, at least on my monitor).
I *am* able to get two different shades of purple, but the lighter one of them is made of 3 pixels in a row... and is displayed as being 4 GR.8 pixels wide (same size as one GTIA mode 9-11 pixel).
...hm, and I just now tried 3 pixels in a row starting on an even column, which appears as a lighter shade of green, and is actually 3 pixels wide.
All these tests were done on an XEGS hooked up to the composite input of a C=1702 monitor, with the text background black (poke 710,0).
So I can get 8 foreground colors on screen at once, plus a black background... but to use some of the colors, I have to give up lots of horizontal resolution, either by leaving blank padding pixels or by putting several lit pixels next to each other.
I still want to mess with Gunstar's paint program, I get the feeling I'm still doing something wrong.
Oh, and S-video does NOT get rid of artifacted colorsYes it does. Artifacting only happens due to the chroma and luma signals being combined. The conditions required to produce artifact colors DO NOT EXIST over an S-Video connection.
Hm, could there be something wrong with a monitor that allows the signals to mix when they shouldn't? If I had an s-video setup, and I skinned the chroma and luma signal wires and shorted them together outside the monitor, or if I shorted the chroma and luma inputs together inside the monitor, would I see artifacts, or would I see a garbage picture, unusable?
Not that I think it would be a good idea, am just trying to understand what's going on...
-
I have a gr. 8 art program (forget the name at the moment , but I'll find it) that lets you display around 9 colors (or more!). It depends on where you place the pixels to achieve different colors. The paint program has tools with the different patterns to automatically choose the colors you want, so you don't have to mess with it.
If you find it, I'd be interested in messing with it. I've spent a good chunk of today with Atari BASIC and GR.8, trying to figure out how to get more than 4 or 5 colors. Even when I'm able to get 5 colors, two of them are so close together that I'm not 100% sure they're different colors
And as for why use artifacting, I, as an artist, thinks its FANTASTIC to be able to use the highest resolution on the 8-bit and have around 9 artifacted colors to use! I LIKE artifacted colors in games too, and if you don't, then just turn down the color! Simple as that.
Ehh, I wasn't trying to say I don't like artifacted colors, or that I didn't want to look at them. I just wanted to know why people choose artifacting over something like GR.15. Now I've got your answer... and it's a good one.
-
some machines have a built in error in BASIC language
This applies to the 800XL, too. I've owned 3 of them and they've all had revision B BASIC...
...but that shouldn't hold anybody back: It really only matters if you're going to write BASIC programs. In that case, you can get a rev. C BASIC cart, or replace the ROM, or use OSS BASIC XL/XE, or Turbo BASIC XL, or a real language (not BASIC at all). Or, you can just live with the fact that rev. B will crash occasionally, and remember to LIST your work to disk every half hour or so.
If you're not going to write BASIC code, you can stick with revision B. It's fine for running programs someone's already written (the fatal bugs are triggered by adding/deleting program lines, which usually doesn't happen while a program's actually running).
-
You forgot that Gr.8 let to display white pixels in hi-res 320x200.
Well, but not really... if you try to display one white pixel, you actually get a red, green, or blue artifacted pixel, double the width of your white pixel (so 160x200 is the effective resolution). If you try to draw something with white pixels, it ends up with color artifacts all over the place... On my Atari right now (XEGS, using composite), I'm looking at a GR.0 screen, and none of the characters look solid white.
Most of artifact color are display in 160x200. In the other side you can get until 9 colors if you know how to control the artifacting technique.
Hm, really? I only know how to get 4... or 5, counting the background, but the colors aren't independent (each pixel's color is partly determined by the pixels to the left/right of it, and partly by where it appears on the scanline).
It's true PAL TV sets are in disaventage with artifact colors, but that isn't a reason to abandon new games or demos with artifact colors.
Oh, I wasn't saying that... I was giving reasons why I, personally, wouldn't use artifacting... but I wouldn't tell anyone else what they should do!
-
Something I've been thinking about on and off for 20+ years...
Why does anyone write a game/demo/etc that uses GR.8 artifacts, instead of using GR.15/Antic E graphics?
The GR.8 and GR.15 modes use the same amount of memory, and both give you 4 displayable colors counting the background... but with a GR.8 display designed to use artifacting, you have a few disadvantages:
- No direct control over the artifacted colors (depends on the TV's color/tint settings, and/or which version of CTIA/GTIA is being used).
- Doesn't work on PAL (well, OK, there's such a thing as PAL artifacting, but it's totally different from NTSC, from what I've read. You'd have to totally redesign your graphics and create separate PAL and NTSC versions of your program).
- Doesn't work on monochrome monitors, or color monitors using the s-video (separate chroma/luma) signal. Even on a green or amber monitor, GR.15 can display 4 different shades of green/amber, but artifacted graphics just come out as closely spaced vertical lines... usually recognizable, but not attractive.
The only disadvantage of GR.15 mode I can think of right now is that the original OS in the 400/800 didn't directly support it, so you have to manually set up the display list (or modify the GR.8 display list) if you want to be compatible with the 400/800. I wouldn't think this would stop anyone but a beginning BASIC programmer from using it, though.
If you're mixing graphics and text, artifacting does let you use the standard GR.0 font wherever you want, I guess that counts as an advantage. To me, it doesn't seem like a good tradeoff for a game, unless it's a text-based game with just a few incidental graphics here and there.
(Everything I just said also applies to GR.0 vs. GR.12/Antic 4, too...)
So... why do people like artifacting? There's obviously no right or wrong answer, I'm just asking for opinions...
-
3. Anything else?
3. Linux/Mac/UNIX support. Even though ProSystem works tolerably well for me on Linux with Wine (except fullscreen!), I'd love to see a native port.
4. Debugger (like Stella has). As far as I know, the only 7800 emulator with a debugger is MESS, which isn't a very good emulator. Good emulator + good debugger = more homebrews, which can only be a good thing.
I may actually take a crack at these myself, if I ever have the time... currently I've got too many half-finished projects (including the Stella debugger itself)
-
Transkey is completely self contained. It even had programable macros as I recall.
Thanks for the link.
That looks like exactly what I'd be looking for. Now to actually find one (if they're still available anywhere)...
-
The only reason the PC case things was feasible was because of Transkey. Although, I had thought of using an XEGS system and it's keyboard.
How compatible is the Transkey? Does it use a modified OS ROM, or is there a driver you have to load... or is it done completely in hardware, so it just emulates the regular keyboard and the Atari never knows the difference?
I don't much care about using a PC case, but an Atari that could use a PC AT or PS/2 keyboard would be sweet. I've got probably 2 or 3 hundred PC keyboards, bought in bulk (nice ones: IBM Model M's, the clicky kind with individual springs)... but if an Atari keyboard dies, it's $20-$30 plus shipping to replace, and a wait of a week while it ships. Also, I like the feel of the IBM keyboards a lot better than any model of Atari keyboard.
The XEGS keyboard is awful... it feels like typing on undercooked spaghetti.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Reading a disk sector
in Atari 5200 / 8-bit Programming
Posted
So the routine at $E453 is just a wrapper that fills in some of the DCB for you and calls SIOV?
Reason I ask is that I've always seen $E459 used to read disk sectors, whether single or double density...