JamesD
-
Content Count
8,999 -
Joined
-
Last visited
-
Days Won
6
Posts posted by JamesD
-
-
Oric has some odd graphics that may prove time consuming to duplicate.
I think the VIC uses a character generator and might be easier to do.
Some modes of the 6847 might be easy to emulate so an Atom emulator (6502) or VZ/Laser emulator might be possible.
-
-
Very nice game, although a bit too easy.We'll have to see how it feels when the fighters follow the arcade movement schemes more closely. There'll be no more non-shooting fighters then, and it'll also have more than one fighter firing at the same time then, which in combination should make it some more challenging. At least I hope so
I have the original version on one of those joysticks with several old arcade games (this is the Space Invaders unit).
The game is a lot of fun and gets pretty difficult after a couple levels.
If the final game matches the arcade, you won't complain about it being too easy.
-
Du-oh!
I missed that!
-
From experience, I can say that very few programs actually use illegal 6502 instructions and thus refuse to run on the new processor. This is like 10 games out of 130 I tested, maybe 2 (rather old) demos out of 40 I tested, I don't recall any utility program which would have problems, but I think one or two can be found, probably.
(beware: OFFTOPIC)
Is there a good reason to use illegal opcodes? Is it possible to make faster code (in some situations) by using them?
Actually yes. There are some illegal opcodes that make conversions between 8 and 16 bits faster (or vice versa). I'm pretty sure there were others as well but those were used so much that Zilog actually made them part of the eZ80 instruction set. Documented this time.
-
One of the advantages of the 65816 is that you could use the DP register to place page 0 type functions elsewhere.
That would let you open up the lower memory map for the speccy so you don't have to translate all the memory addresses.
For ROM you mostly need common entry points like their open ROM project has.
-
Because of the number of colors and the user definable graphics characters it made certain types of games easy to do on the C64 and they looked pretty good.
The Plus/4 was totally character generator based and look what people are doing with it on the game XeO3.
-
Hehe, yep its the same one. Well, I have found if I turn the tv off and on a few times while the atari is on, it will eventually catch the sync. Then it just looks awesome...time will tell if I can put up with it. I tried an XRGB-2 upscan converter, and it works, but looks bad..shimmery and smeary. I am going to be testing some other LCD T.V's and will post results here.
Hmmmm.... and I've been trying it the other way around. Guess I'll have to check that out.
I wonder what the sync is doing it doesn't like... if only I had a scope to hook them up to.
Off and on is too slow but switching sources let mine *kinda* sync to the IIgs so I believe it will work with other sources if I do the same thing. Thanks for the tip!
-
Well, I don't know about capture cards but for tuner/capture cards the ATi 550 or 650 chip sets offer the best quality from the reviews I've seen.
My brother also happens to use one for video capture and it works pretty well. Just remember to always download the latest drivers if you get anything with ATi chips.
Deinterlacing depends on settings in the software.
For capture cards check forums like AVS Forums or MediaPortal forums.
I know some people use those little USB adapters. USB2 is a must for the best quality though.
-
Hehe, yep its the same one. Well, I have found if I turn the tv off and on a few times while the atari is on, it will eventually catch the sync. Then it just looks awesome...time will tell if I can put up with it. I tried an XRGB-2 upscan converter, and it works, but looks bad..shimmery and smeary. I am going to be testing some other LCD T.V's and will post results here.
Hmmmm.... and I've been trying it the other way around. Guess I'll have to check that out.
I wonder what the sync is doing it doesn't like... if only I had a scope to hook them up to.
-
I've tried a couple of experiments with no success... is there a way to get colored text (1 color per line for now) on a Mode 2 line? Maybe with a combination of a DLI?
Once I get that down, I'd like to try exerimenting with setting horizontal colors in a Mode 2 line (something like the Happy Master sector editor)...
If I remember right, the C64 let's you specify colors for each character. Simulating that beyond a color set for each line could be nasty unless you have a similar font mode or have bit mapped graphics with enough resolution and colors to duplicate it by drawing the characters.
-
I have a 15" magnavox LCD TV. It has an s-video input, and so I have a monitor output to s-video cable on my 130XE plugged into it. The picture is WONDERFUL, by far the best I have seen in a while, but....there's a problem. The T.V. seems to have trouble syncing to the signal; more often that not it will pop up as severely vertically offset, with the large black band on the top and bottom wrapped around into a single black band about 30 or scan lines down, and also there's some horizontal offset, although that seems to be variable. About one in ten tries the picture will sync up, so I assume its got something to do with where the T.V. is at scan-line wise when it tries to sync to the signal..or something like that. Anyone have any suggestions?
Thanks.
Well... I think I have the same monitor/TV (silver stand and speaker section but black around screen?) and it has trouble syncing to ANY old computer or game from any input source I've tested (SVID, Composite, RF).
It works fine with VCR or DVD output but I've tried over a dozen old computers and none sync correctly. It's the monitor.
Technically, it will sync to a Coco3 if I reset the Coco repeatedly until it does but that's not very reliable.
No amount of resetting gets it to work with other machines.
I've tested Atari, every Coco model, C128D, Apple II+/IIe/IIc+/IIgs, Franklin Ace, NEC Trek, Nintendo, Space Invaders... and that's just the ones I can think of at the moment.
None sync properly. It's probably the chipset. Sadly, that's part of the reason I bought the monitor. I just didn't test that part until after it was too late to return.
An RGB to VGA converter will probably work though.
-
There was one called something like
The Incredible Monster Machine
-
A woman I worked with has a VCS and Atari computer and plays the "classics" with her great nice when she comes to visit.
She says she likes those games more than her PS2 she has at home.
-
Will any 8-bit game cartridge work on any 8-bit Atari computer? (i.e., any cart will work on the 400, 800XL, 1200XL, etc.)
Some later carts require 64K and don't work on earlier machines.
Some carts supposedly have issues with the ROMs of newer machines. I haven't seen it but it's possible.
The 1200 had some ROM issues so it might not run some stuff.
-
A French guy started the disassembly and he continued from there.
Babel Fish would come in handy.
-
I could have done without his dislocated shoulder during sex blog entry.
It was funny but a bit of an overshare.
Oh, and the entry you linked too was pretty good.
Funny how you remember places because of their smell, the lighting or other atmosphere.
I'm from a pretty rural area and we'd go to the bar to play space invaders, pinball or pool. The place was dark, nasty, smoky and full of power drinkers.
We'd drive to the next town to bowl, play Wizard of Wor and pinball but it was only open certain days. You could hear the Wizard taunting you as you bowled.
Another bowling alley had Star Castle, pinball and pool but during league bowling the smoke would make you choke.
The only local arcade was in a old building with little room but the games were crammed in. I still remember Omega Race next to Defender. Asteroids, Pac Man, Krull (never could master it). It had a slight musty smell and you'd have to wait for someone to make a shot on the pool table to get around it and people crowded at the games. The jukebox was expensive.
When it moved to a larger building I remember Joust, Robotron, Venture... ahhh the left over smell of cigarette smoke from the bar that used to be there. They didn't even paint the walls. Now you could buy pop and there was plenty of room for the pool tables. The jukebox was still expensive.
Pacman was in the Safeway and later Sinistar. It made going shopping with my mom tolerable.
A sit down Asteroids Deluxe sat in the Dairy Queen and was later replaced with Donkey Kong Jr. It was a great spot because the owner's daughters worked there and they were HOT! It also had the best chicken, burgers and shakes. The only problem was that some kid would always be there hogging the game and the owner would have to kick him off so paying customers could play.
When I went to college the game room in the student center had a pinball machine I could play a half hour or more on a quarter. It was my favorite spot between calculus class and history. I worked out my frustration on it. 'Rock Me Tonight' by Billy Squire or 'The Warrior' by Scandal always seemed to be playing on the jukebox. I remember hearing that Asia broke up around that time.
The local bowling alley had Time Pilot and Decathlon among others but it was at the other end of town and I spent most of my time playing basketball or at the bar... California Coolers were the thing then. I remember Van Halen's 1984 came out around that time and the kid on the cover looked EXACTLY like my nephew. 'Jump' was constantly playing on the jukebox as well as 'Love Grammar' and 'Summer of 69'.
After transferring to a University their student center game room had Mortal Combat at some point and some sit down games but I didn't even know it was there for a long time. The only game I remember was Mortal Combat. I was more interested in a woman and video games were the last thing I though of.
The arcade at the mall had the pinball game Genesis but I don't remember much else except the attendant giving me an hour of free play on Joust after the token machine didn't give me tokens.
It seems to me things were going down hill at this point. The arcades were asking for more tokens/play or reduced the number of plays. On top of that games that were coming out were starting to be copies of each other. I also became a partner in a business the 2nd year I was there and ended up spending all my time working.
Now I have to go to Dave & Busters or Red & Jerry's in the Denver area to see anything like an arcade. The $10 that would last me hours now lasts about 15 minutes... counting wait time at the games.
-
Oh boy.......
Really even if this thing does pass. Your still gonna have irresponsible parents allowing their juvenille deliquent, uh I mean children, access to this stuff.
Where the problem has always existed.
The parents are usually the problem anyway. They pay no attention to what their kids are doing and expect them to turn out ok.
I'll never forget leaving a Best Buy behind a woman and what had to be her 8 year old. She was buying what he wanted... a rated M game and a cheat guide to another rated M game. I guess she thought her child was mature or just didn't pay attention.
One of the things I hate about the M rating is it's more obscure than an R or PG type of rating.
-
But did you do anything useful with it?
-
BTW, just because a compiler isn't 100% ANSI doesn't mean it isn't any good.
Also, I did some reading on a Oric forum and found that lcc65 or whatever they are using promotes int to 16 bit. While this does follow the standard you do need to be aware of it. If you want to use a byte then use char. This should hold true for any ANSI compiler.
-
It is ANSI compatible. No floats. But very cool linker that makes allocating code for page swapping easy. It also has a nice set of loadable drivers for joypads, screen i/o and filesystem.
And it is cheap - free.
--
Karri
Ok, first of all ANSI requires floats so that alone means it's not.
Second, have you run any compatibility tests to verify compatibility like the test suite GCC uses?
I'm guessing no. Those tests are nasty and bring out minor flaws in compilers that can cause some real problems.
ANSI isn't just changing calling parameters from K&R format and a few things like that. Certain code must be compiled a certain way.
If ANSI is the final goal and you are close... fine that's cool, but that isn't the same thing as writing some C, testing it natively on a PC, then expecting it to recompile and run as is on a target 6502 machine. I'm not trying to be nasty, its just that I've tried porting code from one compiler to another way too many times where I had to rewrite valid code because of a flaw in the parser or code generator and that's even with commercial compilers.
The linker and drivers sound neat. Free is always good and I have checked on the project from time to time so I do know a lot of progress has been made over the years.
My comment about lcc65 was because I know it's based on a proven ANSI front end that optimizes intermediate code pretty well even before generating 6502 assembly. In spite of the ANSI front end that still doesn't mean lcc65 is full ANSI because the code generation may not be right... but at least it has a high probability of being ANSI.
-
It has very good support for different 65-series CPU's.
--
Karri
Yeah, but how ANSI compatible is it? While I here it's very usable, I thought you did have to program around it's limitations. But I haven't tried it so I don't know. Still no floats I'm guessing.
Wasn't there another 6502 compiler that had a better compiler front end but didn't optimize well on the back end?
I think people claimed it still produced faster code. I think it was called lcc65?
I know Z88dk is a pretty decent Z80 cross compiler but the last version I used still had some missing stuff that my program needed. I haven't tried the latest version but it sounds promising... still no support for what I needed though.
SDCC looks like another good Z80 cross compiler but the version I tested crashed at times. The current version fixed the crashes but I haven't tried building any of my stuff because I'd need to port the Z88dk libs.
I was working on a port of SDCC for the 6809 and actually had a large portion of the code generator completed but other things have taken my time for the last few months... which wasn't a bad thing since it's given me time to think a few things through and see how another 6809 compiler works. I started looking at how GCC for the 6809 does things and I realized it would be better to allocate registers in a different order. Trivial to fix but it *should* result in faster numeric conversions. There were a lot of other things I needed to figure out before going on (PC relative code, system vs user stack, DP addressing...) and I've finally decided how to deal with them. I guess it's time to get busy again.
-
I think line numbers were normally stored as a 16 bit integer all the way back to the early tiny BASIC interpreters for the first hobby computers.But they weren't tokenized in GOTO/GOSUB statements. Trust me, I've disassembled lots of versions of MS-BASIC, starting with the TRS-80. Atari's BASIC was the first "pack-in" BASIC to tokenize line numbers inside a line.
I wasn't aware of that... and it makes me wonder what they were thinking since it's such an obvious way to speed up BASIC.
-
There also could be some savings from not interpreting line numbers and numeric constants all the time, but Atari BASIC and later versions of Microsoft BASIC (CP/M, 8086, 68000) tokenized those as well.
EDIT: oh yeah, and line number searches in MS-BASIC were linear as well, with the only optimization being a compare of the current line number with the desired line number. If it was a later line, it started the search from the current line instead of the start of the program.
I think line numbers were normally stored as a 16 bit integer all the way back to the early tiny BASIC interpreters for the first hobby computers. That also explains the limit on what line numbers can be used. I'm not aware of any versions that use floats for line numbers including many that otherwise only use floats. That includes Atari BASIC, Tandy CoCo BASIC and I think Sinclair BASIC. Those would be the first ones that come to mind. I don't remember if Applesoft had INT or not but since the Apple Integer BASIC was much faster I'm guessing it also was float only for numeric variables.
On the other hand, the Atari corp Assembler cartridge (from what I understand) used floats for line numbers and it was much slower than it's competitors.
I think the test to see if the line number called by a goto or gosub follows the current line was common.
The pointer idea used by that version of Atari BASIC was pretty unique and the way it *should* have been handled.
A similar optimization could have been used for variables but I'm not sure if it was ever used. Variables should have had an index into a table of pointers that linked to the actual variable. That way if the interpreter moved a string or other variable at runtime all that would need adjusted is the pointer in the table and it's much faster than searching a linked list.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
So what's wrong with Donkey Kong?
in Atari 7800
Posted
Not an official port but the Tandy Coco version:
http://nitros9.lcurtisboyle.com/donkeyking.html
It matched the arcade pretty well in layout, number of screens and gameplay.
Yeah... the sound leaves a lot to be desired like most Coco titles and the artifact colors aren't true to the arcade but that was life in the Coco lane until the Coco3.
Here is the Donkey Kong Jr clone for the Coco1/2:
http://nitros9.lcurtisboyle.com/juniorsrevenge.html
and for the Coco3:
http://nitros9.lcurtisboyle.com/returnjuniorsrevenge.html
I thought the reason so many Kong versions were backwards was because they couldn't fit another level on the shorter screen without shortening the ladders and changing the gameplay. Either way they changed it so I don't see the advantage myself.