C16 played Atari 2600?
Bill H
"The C16 retailed for only $70 Australian in a time when the C64 was
$400+ Australian (1985). Due to the flop of sales, it was barely
impossible to purchase peripherals such as the tape drive or disk
drive listed in the manual. One alternative was that the cartridge
slot was had pretty much the same pin out as an Atari 2600 games
console, and a 'small' basic program (Small being less than 1000
lines) could launch it away to run in BASIC 3.5 - just so long as you
had enough RAM left for it to even start."
on: http://www.old-computers.com/museum/doc.asp?c=97
Is it true that the C16 could play the Atari 2600 games? How?
Bill H
Riccardo Rubini
> on: http://www.old-computers.com/museum/doc.asp?c=97
>
> Is it true that the C16 could play the Atari 2600 games? How?
I've never heard about it, but it sounds like bullshit. Give a look at the
edge connector of an Atari 2600 cartridge:
http://www.gamasutra.com/features/20030226/atari-2600-pcb.jpg
Does it resemble in any way or form the C16 edge connector?
http://www.floodgap.com/retrobits/ckb/secret/cbm-1551-tcbmi.jpg
Absolutely not. Case closed.
Riccardo
Bill H
It did say they were "pretty much the same". But the interesting thing
it said was that a small basic program would let you play them. That
is the "How" I was wondering about. Would it have been possible to
emulate the Atari 2600 in Basic on the C16 and then "play" the Rom?
The 2600 wasn't all that powerful inside and the programs were often
small.
Bill H
Bill H
>
> - Show quoted text -
A little more on the Specs of the 2600:
CPU 6507
Ram: 128 bytes
Rom: 4kb max
Graphics: 160 x 192, 128 colors (16 colors, 8 levels)
Sound: 2 mono channels
With such limited specs I would think that the C16 (or any other
commodore) could handle this (not sure in Basic though).
Bill H
Dombo
I am pretty sure it is impossible, especially if you consider how the
video display on the Atari 2600 worked. The 2600 didn't have video
memory which it would read autonomously, like on the Commodore and most
other computers. Basically the video chip on the 2600 is one
dimensional, it only knows how to display on horizontal line. If you
want the next line to be different from the previous line the video chip
had to be reprogrammed. Since 15625 (PAL) or 15734 (NTSC) times a second
a new line is written on the video screen, it requires accurate timing
from the software. Due to the entirely different hardware on the
Commodore's it is not possible to achieve that precise timing and
emulate the hardware as well. The fact that the hardware on the
Commodore is in many respects more powerful doesn't really help.
For the Coleco console there has been a cartridge that added the ability
to play Atari 2600 games. Essentially this was nothing more than a full
2600 system on a cartridge, the console itself was more or less degraded
to a power supply.
Riccardo Rubini
> It did say they were "pretty much the same".
Well, they aren't even remotely.
> But the interesting thing
> it said was that a small basic program would let you play them.
Basically, the only meaning out of that sentence that would make sense is
that some Basic program did exist, for the C16, that was able to work as an
interpreter between the two systems, right? I am very skeptical, because the
two systems are very different hardware-wise.
> That
> is the "How" I was wondering about. Would it have been possible to
> emulate the Atari 2600 in Basic on the C16 and then "play" the Rom?
I gather the Atari 2600 was an inferior product, compared to the 264 line,
however, I question seriously the speed of such "virtualization".
> The 2600 wasn't all that powerful inside and the programs were often
> small.
From a recent discussion, we gathered that the 7501 works at 1.76 Mhz, when
it's not talking to the bus or I/O. The 6507 should be stuck at 1 Mhz, I
suppose. You have to keep into account, though, that the "virtualization"
would take away a lot of CPU cycles. The CPU instructions are the same, but
the hardware, memory locations and firmwares are very different. Can you
forsee that working at reasonable speed? I don't. Maybe the author of that
homepage can post a link to this fabeled program and surprise us all.
Riccardo
Brian Ketterling
Bill H <bi...@ts1000.us> wrote:
> "One alternative was that the cartridge slot was had pretty much the
> same pin out as an Atari 2600 games console"...
What the heck does "purdy much" /mean/?
> ..."a 'small' basic program (Small being less than 1000 lines)"...
!?!
> ..."could launch it away to run in BASIC 3.5"...
The ML in a cartridge could be run as BASIC statements?
Hmm... was the author Paul Panks?
Brian
--
winston19842005
On 1/27/08 7:19 AM, in article
02bd0c04-0370-4e57...@e25g2000prg.googlegroups.com, "Bill H"
<bi...@ts1000.us> wrote:
Noting that the quote was from a Mr. "Richard Headley"...
We used to use that term when I was younger in place of the more oft-used
"Dickhead".
Hmm. Might that be a give-away? Or this poor bastard has such an unfortunate
name?
Bill H
> On 1/27/08 7:19 AM, in article
>
> - Show quoted text -
I'm not gonna make any comment on the name :) , or the validity of
there having been a program in Basic to do it back then. But exploring
the possibility of doing it, the 2600 cart is only a 4 kb rom chip. I
am sure you could wire up an adapter that would map that rom into the
C16's memory space. Now Basic would be too slow to emulate a 2600
(IMO), but I believe you could use ML to do it, it may crawl, but
since the emulation overhead is so low (you are only emulating the
video hardware, sound and joystic/paddle input) it "should" be doable.
Since the program you are emulating is already mapped into the memory
space, you don't need any Ram to hold it and accessing it would be
fast. As a "thought-experiment" it would be an interesting concept, if
not for the C16, then for the C64.
Bill H
BruceMcF
converting code written for the Atari 2600 using some specific
programming framework into code for the C16. AFAIU, there were a
number of cross-platform console programming frameworks, back in the
day.
Less plausible, but conceivable, would be a raw code translation
system, that reads 6502 machine code for writes to the Atari Video
hardware and translates them into writes to an emulated Atari screen
in RAM, with a process running on the interrupt to translate from that
to the actual VIC screen on an ongoing basis.
An emulator as such would require dedicated hardware ... the C16
processor is not fast enough to emulate the Atari 2600 hardware as
well as running the game code at the same time. Unless there was a
cartridge that had an Atari connector on the back and trapped writes
to the Atari video system space on the fly, writing the result to the
C16 display processor memory space using DMA??? I think someone would
have heard of such a weird beast long before now.
Dombo
The problem with the way the 2600 works is that the emulation _must_ run
at 100% speed for it work (as explained in my other post). Also the 6502
does not offer ways to trap hardware accesses, which would make
emulating non-existent hardware difficult for trivial cases and
impossible for non-trivial cases.
> Since the program you are emulating is already mapped into the memory
> space, you don't need any Ram to hold it and accessing it would be
> fast. As a "thought-experiment" it would be an interesting concept, if
> not for the C16, then for the C64.
I think you should learn a bit more about the technology involved before
making statements that something is feasible.
Cameron Kaiser
>I'm not gonna make any comment on the name :) , or the validity of
>there having been a program in Basic to do it back then. But exploring
>the possibility of doing it, the 2600 cart is only a 4 kb rom chip. I
>am sure you could wire up an adapter that would map that rom into the
>C16's memory space. Now Basic would be too slow to emulate a 2600
>(IMO), but I believe you could use ML to do it, it may crawl, but
>since the emulation overhead is so low (you are only emulating the
>video hardware, sound and joystic/paddle input) it "should" be doable.
>Since the program you are emulating is already mapped into the memory
>space, you don't need any Ram to hold it and accessing it would be
>fast. As a "thought-experiment" it would be an interesting concept, if
>not for the C16, then for the C64.
You would also have to remap the TIA's registers to match, because the
TED (or VIC) is still at its usual location, the palette would be wrong,
and the 7/8501 is not running at a fixed 1MHz.
If you tried to do this in software, it would never be fast enough to
work effectively. Trust me on this:
http://www.floodgap.com/retrobits/kim-1/emu.html
It would require so much effort that you might as well get a 2600 and
run it on the real thing. All the systems I've seen that 'emulated' the
2600 (including the Intellivision and ColecoVision adapters) just had
2600 hardware in them and used the primary console pretty much just
for its controllers and TV out.
--
Cameron Kaiser * cka...@floodgap.com * posting with a Commodore 128
personal page: http://www.cameronkaiser.com/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **
Jim Brain
enough to do, the C64 could have easily emulated the VIC-20.
I'm amazed the 2600 games run at all, given how the screen is generated.
Jim
Simon Scott
> Hmm. Might that be a give-away? Or this poor bastard has such an
> unfortunate name?
There's a guy on the Perth Linux User Group's list called Michael Hunt,
so anything's possible I guess....
Riccardo Rubini
> Less plausible, but conceivable, would be a raw code translation
> system, that reads 6502 machine code for writes to the Atari Video
> hardware and translates them into writes to an emulated Atari screen
> in RAM, with a process running on the interrupt to translate from that
> to the actual VIC screen on an ongoing basis.
The C16 doesn't use the VIC, but the TED. Which is severely crippled
compared to the VIC-II graphic chip. You need to emulate sprites in software
with it, to add insult to injury.
I am surprised we're still discussing about this bogus project with no
potential application nor any use.
Riccardo
christianlott1
> The C16 doesn't use the VIC, but the TED. Which is severely crippled
> compared to the VIC-II graphic chip. You need to emulate sprites in software
> with it, to add insult to injury.
> I am surprised we're still discussing about this bogus project with no
> potential application nor any use.
But the idea is pretty cool and I think it has been discussed before.
Maybe a more likely possibility is an automatic translation where a
program reads the Atari file and compiles it to code for the C64. On a
second phase you might have settings you could tweak on the
translation.
On a related note:
There's a lot more information on the TIA online now than there was
years ago. Searching for "Atari TIA" gives a detailed explanation of
inner workings. There's also a slew of patents related and referenced
for it I collected from http://www.freepatentsonline.com
TIA patent and seven referenced patents:
http://70.116.26.17:6809/Uploaded/tia.zip
More links:
http://www.howell1964.freeserve.co.uk/Atari/tia/index.htm
BruceMcF
> BruceMcF wrote:
> > Less plausible, but conceivable, would be a raw code translation
> > system, that reads 6502 machine code for writes to the Atari Video
> > hardware and translates them into writes to an emulated Atari screen
> > in RAM, with a process running on the interrupt to translate from that
> > to the actual VIC screen on an ongoing basis.
> The C16 doesn't use the VIC, but the TED. Which is severely crippled
> compared to the VIC-II graphic chip. You need to emulate sprites in software
> with it, to add insult to injury.
I have the C16 confused with another stripped down cbm machine
then ... not surprising, as I only ever had C64's and C128's ...
... with VIC sprites, and the ability to swap sprites with a single
register write on each scanline, providing an emulation of missile-
player graphics is straightforward. Without sprite hardware ... no
wonder the gimp didn't take off.
BruceMcF
> But the idea is pretty cool and I think it has been discussed before.
> Maybe a more likely possibility is an automatic translation where a
> program reads the Atari file and compiles it to code for the C64. On a
> second phase you might have settings you could tweak on the
> translation.
More plausible with a C128 running native 2MHz ... it could toggle
back and forth between an Atari translation engine running for one
scanline and the translated code running for the next, reducing the
work required of the translator.
Huh, too bad they didn't think of that when they were introducing the
C128, it would have created an additional reason to buy one that
involved running it in C128 mode. Also too bad they did not run the
Z80 on the dot clock with wait states to synchronize with the system
bus, then the CP/M would have been competitive with the current CP/M
state of play.
MagerValp
BH> since the emulation overhead is so low (you are only emulating the
BH> video hardware, sound and joystic/paddle input) it "should" be
BH> doable.
Newsflash: video emulation is the hard part.
You need a 166 MHz PC to emulate a 2600, a 1 MHz 6502 doesn't even get
you close.
--
___ . . . . . + . . o
_|___|_ + . + . + . Per Olofsson, arkadspelare
o-o . . . o + Mage...@cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
iAN CooG
> The C16[...]
> I am surprised we're still discussing about this bogus project with no
> potential application nor any use.
WTF? Are you joking?
Now go to http://plus4.emucamp.com, watch some of the demos and try to
repeat there what you just wrote!1!1 :D
C16 and plussy rox. Some stuff are even impossibile to do on C64.
Well C16 has less than 16k ram available and +4 is preferable, but hey,
we're talking about machines were code optimizations DO COUNT.
--
-=[]=--- iAN CooG/HokutoForce ---=[]=-
Linking error. Your mistake is now in every file.
Riccardo Rubini
> Huh, too bad they didn't think of that when they were introducing the
> C128, it would have created an additional reason to buy one that
> involved running it in C128 mode. Also too bad they did not run the
> Z80 on the dot clock with wait states to synchronize with the system
> bus, then the CP/M would have been competitive with the current CP/M
> state of play.
Well, while we're at it, why not having a ZX Spectrum emulator for the C128?
After all, they could share the same CPU ( Z80 ). The Spectrum was such a
piece of crap it wouldn't surprise me to see it perfectly emulated on the
C128. When I opened up a Speccy I got for 1 EUR from a Gypsy ( no pun and no
joke, guys ) I couldn't find anything else than the ULA and the Z80. The ULA
is a gate array... What did that toy use for graphics?
Riccardo
Riccardo Rubini
> Riccardo Rubini <rub...@despammed.com> wrote:
>> The C16[...]
>> I am surprised we're still discussing about this bogus project with
>> no potential application nor any use.
>
> WTF? Are you joking?
No. You just didn't get what I meant. The "project" I am talking about is
the Atari emulation on the C16. Absolutely useless and, worse, completely
bogus.
> Now go to http://plus4.emucamp.com, watch some of the demos and try to
> repeat there what you just wrote!1!1 :D
I have been an happy Plus/4 years for over 10 years, now. I honestly don't
give a fuck about demos, but I do enjoy the huge amount of quality
applications that do exist for the CBM 264 line.
> C16 and plussy rox. Some stuff are even impossibile to do on C64.
To each its own. I don't know what you're talking about here, though.
Probably you're talking about the extra colours the TED brings in.
> Well C16 has less than 16k ram available and +4 is preferable, but
> hey, we're talking about machines were code optimizations DO COUNT.
Code optimization counts in the 8086, 80386, Pentium etc. world too... While
it was a curse to write "mov ax,0" back in the day, and nowadays is
overlooked because of the Ghz race, writing crappy code still sucks
regardless.
Riccardo
Riccardo Rubini
> ... with VIC sprites, and the ability to swap sprites with a single
> register write on each scanline, providing an emulation of missile-
> player graphics is straightforward. Without sprite hardware ... no
> wonder the gimp didn't take off.
Well, the CBM 264 line runs a little faster, in terms of CPU. You can
emulate the sprites via software. The results aren't that bad at all. You
can check out some games and see that it's hard to notice the difference, in
terms of pure speed, but some games definitely look crappier than their C64
counterpart - in most cases, that's just the programmer's fault. For
example, GEOS on the Plus/4 looks just like the C64 version, or even better.
Riccardo
Andrew Schwartz
that had a cartridge port emulator to allow your C=64 to run 2600
cartridges.
Commodore VIC-20/2600 game adapter - Rumored to exist. Was advertised by
Protecto in mail order ads in during the 1983 time frame. Plugged into VIC
expansion connector and provided 2600 software emulation. Original price,
emulation quality, and reliability all unknown.
The September 1983 issue of Electronic Games (page 41) shows an
advertisement for Cardapter, a 2600 cart adapter for the Vic-20. The
distributor was Cardco, Inc. in the US, LSI Distributors Ltd in W est
Canada, Hobby Craft Canada in East Canada, and Audiogenic in Europe.
Additional information on this bit would be interesting.
Andy
"Dombo" <do...@disposable.invalid> wrote in message
news:479c8a7f$0$24433$5fc...@news.tiscali.nl...
Sam Gillett
"Riccardo Rubini" wrote ...
> When I opened up a Speccy I got for 1 EUR from a Gypsy ( no pun and no
> joke, guys ) I couldn't find anything else than the ULA and the Z80. The
> ULA is a gate array... What did that toy use for graphics?
IIRC, it used the CPU to do the display, which took away from the amount of
time that the Z80 could use to actually run the program.
That is only one reason the C64 can do more in spite of it's lower clock
speed. The C64 has a coprocessor, the VIC chip, to handle the grunt work of
producing the display.
--
Best regards,
Sam Gillett
Change is inevitable,
except from vending machines!
christianlott1
wrote:
> Right after I got my C=64 in 1983 I saw an ad in one of the computer mags
> that had a cartridge port emulator to allow your C=64 to run 2600
> cartridges.
>
> Commodore VIC-20/2600 game adapter - Rumored to exist. Was advertised by
> Protecto in mail order ads in during the 1983 time frame. Plugged into VIC
> expansion connector and provided 2600 software emulation. Original price,
> emulation quality, and reliability all unknown.
>
> The September 1983 issue of Electronic Games (page 41) shows an
> advertisement for Cardapter, a 2600 cart adapter for the Vic-20. The
> distributor was Cardco, Inc. in the US, LSI Distributors Ltd in W est
> Canada, Hobby Craft Canada in East Canada, and Audiogenic in Europe.
> Additional information on this bit would be interesting.
> > Dombo wrote:
> > For the Coleco console there has been a cartridge that added the ability
> > to play Atari 2600 games. Essentially this was nothing more than a full
> > 2600 system on a cartridge, the console itself was more or less degraded
> > to a power supply.
So maybe they had a TIA on a cartridge with a video/audio out?
What would be the point? Load games from disk I guess.
How difficult are TIAs to get these days?
Know1
"christianlott1" <christi...@yahoo.com> wrote in message
news:6907f6b9-f243-423a...@i29g2000prf.googlegroups.com...
Why bother; when you can emulate every
thing on your PC?
Got a good collection here.
Thanks much to the emu programmers for that;)
>
christianlott1
> "christianlott1" <christianlo...@yahoo.com> wrote in message
> > So maybe they had a TIA on a cartridge with a video/audio out?
>
> > What would be the point? Load games from disk I guess.
>
> > How difficult are TIAs to get these days?
>
> Why bother; when you can emulate every
> thing on your PC?
I'm interested in the real hardware. No bother.
> Got a good collection here.
> Thanks much to the emu programmers for that;)
I do too, but there's nothing like playing on real hw.
Also, if there was a new board made it could incorporate the s-video
and stereo mods. You'd also have greater than 4k program space.
It's a stupid idea - but that's never stopped innovation.
Know1
"christianlott1" <christi...@yahoo.com> wrote in message
news:a58b150d-05cc-467d...@f10g2000hsf.googlegroups.com...
> On Jan 29, 9:08 am, "Know1" <Kn...@home.com> wrote:
>> "christianlott1" <christianlo...@yahoo.com> wrote in message
>> > So maybe they had a TIA on a cartridge with a video/audio out?
>>
>> > What would be the point? Load games from disk I guess.
>>
>> > How difficult are TIAs to get these days?
>>
>> Why bother; when you can emulate every
>> thing on your PC?
>
> I'm interested in the real hardware. No bother.
>
>
>> Got a good collection here.
>> Thanks much to the emu programmers for that;)
>
> I do too, but there's nothing like playing on real hw.
I, as well.
I have the following (in no specific order)
C64 /Amiga A600/A1200
PS1/PS2
Nintendo/SNES/Nintendo64/Gamecube
Xbox/Xbox360
PC/386 to I386
And all emulated on my PC.
hg
You have a Xbox360 emulator running on your PC?!
Know1
"hg" <h...@hg.hg> wrote in message news:MeqdnduOUsD89wLa...@pipex.net...
> You have an Xbox360 emulator running on your PC?!
>
Yep
Mark McDougall
> Now Basic would be too slow to emulate a 2600
> (IMO), but I believe you could use ML to do it, it may crawl, but
> since the emulation overhead is so low (you are only emulating the
> video hardware, sound and joystic/paddle input) it "should" be doable.
> Since the program you are emulating is already mapped into the memory
> space, you don't need any Ram to hold it and accessing it would be
> fast. As a "thought-experiment" it would be an interesting concept, if
> not for the C16, then for the C64.
As others have pointed out, the possibility of emulating a 2600 on a C16 is
so far from feasible it's not even worth wasting your brain cells on a
"thought experiment". As Per pointed out, think about the fact that it takes
a P166 - with megabytes of RAM - to emulate a 2600... and you want the
C16/64 to do it? Dreaming...
Speed issue aside, there's plenty of other hardware compatibility problems.
The video generation on the 2600 is so f***ed^H^H^H^H^H^H tightly coupled to
timing and interrupts that without a virtual machine framework you've
absolutely no hope of reproducing the video on another machine via
"translation". You can't emulate hardware - registers and ports - without
virtualising the whole machine. And emulating CPUs and video takes a
sh*t-load of CPU time - many many cycles per emulated machine cycle.
I can't vouch for the rumoured hardware adapters, but even those I'd tend to
dismiss without concrete proof. You basically need a 2600-in-a-cart to run a
2600 game on a C16/64, with the latter doing little more than "screen
scraping" and providing joystick input.
Regards,
--
| Mark McDougall | "Electrical Engineers do it
| <http://members.iinet.net.au/~msmcdoug> | with less resistance!"
christianlott1
> "hg" <h...@hg.hg> wrote in
> > You have an Xbox360 emulator running on your PC?!
>
> Yep
probably runs slow.
That's the problem though. Emulators are cool but if you don't have a
dedicated dos box - you run on top of windows which will not provide
real time emulation. It's worthless except for previewing what you'll
run on real hw.
John Selck
> More plausible with a C128 running native 2MHz ... it could toggle
> back and forth between an Atari translation engine running for one
> scanline and the translated code running for the next, reducing the
> work required of the translator.
And how do you convince the Atari code to jump to the translation
code?
Dombo
The ULA.
David Murray
that a properly working emulation of the 2600 on any 8-bit Commodore
product is not very likely. One major problem I see that nobody else
has mentioned is that the VIC-II and the TED are simply not capable of
reproducing the video display of the 2600. Although I'll admit that
the TED and VIC-II are both superior video devices, they are both
limited by color-cell systems which the 2600 is not. Not only that,
but I believe the 2600 can do considerably more colors than the VIC-
II.
A pointless experiment would be to see if you could even get Atari
2600 code to run on a commodore product, minus the video, audio, and I/
O. How you would actually tell if it is running is another story.
The one thing that would be in your favor is the small code size. At
least it fits in a single bank of RAM and wouldn't have to overlap
into other banks, so that would solve a code-nightmare.
I would be willing to entertain the possibility that a well-written
emulator for the Amiga 1000/500 might be able to achieve 2600
emulation. After all, there was a C64 emulator that I used to run on
my A500. it was slower than a real C64, but taken into account the
extra simplicity of the 2600 it might just be possible.
John Selck
> One major problem I see that nobody else
> has mentioned is that the VIC-II and the TED are simply not capable of
> reproducing the video display of the 2600.
Why not? 2600 is mostly single color + color bars + different color
PM's on top. Even though an emulation would be impossible, the TED
could easily display the same graphics.
> Although I'll admit that
> the TED and VIC-II are both superior video devices, they are both
> limited by color-cell systems which the 2600 is not.
The color cells are actually extending the possibilities not
limiting them. Look at the Atari 8 bit computers (they are the
offspring of the 2600): They have 320x200 in 2 colors and
160x200 in 4 colors. C64/TED can easily do that if the color cells
are not used.
> After all, there was a C64 emulator that I used to run on
> my A500. it was slower than a real C64, but taken into account the
> extra simplicity of the 2600 it might just be possible.
A64? That was more like a simulator than an emulator. It ran a few
programs, but was VERY inaccurate.
David Murray
> PM's on top. Even though an emulation would be impossible, the TED
> could easily display the same graphics.
It isn't so much what the graphics looked like to the human eye,
rather how it is laid out on the screen. The code for the 2600 may be
expecting to change colors whenever it feels like it in the process of
drawing a line on the screen. The place it chooses to change won't
always line up with a color cell on the Commdore's screen. Sure, you
could write some fancy code to allow the C64 to emulate the screen by
cleverly arranging pixels in the multi-color 160x200 mode.. but then
the CPU overhead would become enormous.
> The color cells are actually extending the possibilities not
> limiting them. Look at the Atari 8 bit computers (they are the
I never said the color cells weren't a good idea or that they didn't
make the chip better than the 2600's graphics.. but nevertheless, from
a standpoint of emulation it would make it 100 times more complicated.
Mark McDougall
> A pointless experiment would be to see if you could even get Atari
> 2600 code to run on a commodore product, minus the video, audio, and I/
> O. How you would actually tell if it is running is another story.
Interesting that you mention it. When I ported Space Invaders to the TRS-80
Model 4P, the 1st step was to actually see the code running. I was fortunate
in that the entire SI memory map overlapped the 4P RAM and, both being Z80,
it just required the interrupts to be tickled.
I then periodically (1/sec) jumped out of the ISR to a routine that dumped
the SI video RAM onto the 4P display - so I could see that it was in fact
running perfectly!
<http://members.iinet.net.au/~msmcdoug/sitrs/index.html>
Of course, I had the benefit of running SI on the XTRS emulator on linux, so
I had full visibility of the memory space and CPU state etc. But in theory I
could have done it on a real 4P...
Unfortunately, as you are no doubt already aware, there was no "video RAM"
on the 2600 (IIUC) so you can't simply "screen scrape" periodically to show
on the commodore display (this is all aside from the fact that there are
different processors involved).
ap...@chebucto.ns.ca.nospam
2600 games:
With the inclusion of a Starpath Supercharger. Apparently there is
downloadable software for the c64 (&pc's), that will run 2600 immages
through the sound out connect of the c64 to the Starpath cartridge and
hence to the monitor. Not clear if the images are just Supercharger games
or any 2600 game. I think Robin Hebron (sp?) was instrumental to this
approach.
John Elliott
Cameron Kaiser
>>Although I'll admit that
>>the TED and VIC-II are both superior video devices, they are both
>>limited by color-cell systems which the 2600 is not.
>The color cells are actually extending the possibilities not
>limiting them. Look at the Atari 8 bit computers (they are the
>offspring of the 2600): They have 320x200 in 2 colors and
>160x200 in 4 colors. C64/TED can easily do that if the color cells
>are not used.
I think David was getting at changing colours as much as every raster
line, or in the case of the Atari 8-bits, display lists. Also the larger
palette helped.
--
Cameron Kaiser * cka...@floodgap.com * posting with a Commodore 128
personal page: http://www.cameronkaiser.com/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **
Cameron Kaiser
No, the Supercharger just downloaded the games to the 2600, essentially
making the 64 (or whatever host computer was involved) its "cartridge
server." Although very useful, it was not an emulator at all as the object
code was still running on the 2600.
christianlott1
> ap...@chebucto.ns.ca.nospam writes:
> >Not quite what was asked but a Google search will show that C64 will run
> >2600 games:
> >With the inclusion of a Starpath Supercharger. Apparently there is
> >downloadable software for the c64 (&pc's), that will run 2600 immages
> >through the sound out connect of the c64 to the Starpath cartridge and
> >hence to the monitor. Not clear if the images are just Supercharger games
> >or any 2600 game. I think Robin Hebron (sp?) was instrumental to this
> >approach.
>
> No, the Supercharger just downloaded the games to the 2600, essentially
> making the 64 (or whatever host computer was involved) its "cartridge
> server." Although very useful, it was not an emulator at all as the object
> code was still running on the 2600.
Are you talking about :
"Charger up! The VIC-20 to Atari 2600 'Ram Cartridge' Programmer",
Ravid Noam. Hardware project.
in issue 2 of disc+overy?:
http://www.ffd2.com/fridge/discovery/
btw Mark, that's a pretty cool project!
David Murray
didn't even know the Tandy model 4 could even do graphics.
Being that many early arcades were Z80 based, it makes me wonder if
any of them could be ported to run on the C128.
Mark McDougall
> Wow.. I hadn't seen the port of SI on the Tandy.. that is cool. I
> didn't even know the Tandy model 4 could even do graphics.
Out-of-the-box, no, but aside from the Tandy offering there was a
(compatible) hires board from MicroLabs that offered up to 640x240
monochrome dot-addressable (bitmap) graphics, mapped via I/O registers
(SLOW!) to a bank of SRAM.
> Being that many early arcades were Z80 based, it makes me wonder if
> any of them could be ported to run on the C128.
I patched the (relatively few) video update routines in Space Invaders
on-the-fly (so you can use the original roms unchanged) to draw (also) to
the Model 4P hires display (keeping the original bitmap memory in-tact for
read-back when masking). Although there's not a whole lot of video updates
happening on SI, the port-mapped I/O is *very* slow, so it requires the 4P
running in fast mode (4MHz) even though SI ran at 2MHz.
Aside from that, you need to emulate the graphics shift register in software
(trivial), generate a 120Hz interrupt and of course patch the
coin/controller inputs. If the 128 can map $0000-$3FFF to RAM on the Z80,
then it should be trivial. With bit-mapped graphics, there may be enough
headroom to still run it at 2MHz...
I looked at a few of the early Z80-based games, including Pacman as you can
see on my page, but aside from the Midway8080 (SI) hardware, there's very
little else that will run on a 2MHz CPU - at least without much in the way
of special graphics hardware. Games like Galaxian and Frogger used sprites
and scrolling tilemaps, the latter, IIUC, would need to be emulated in
software on the C128...
But I think SI would be worth investigating!
John Selck
wrote:
> I think David was getting at changing colours as much as every raster
> line, or in the case of the Atari 8-bits, display lists. Also the larger
> palette helped.
Yes but you can do exactly the same on VIC-II/TED. And display lists do
NOT change colors. You still have to do it with the CPU.
Cameron Kaiser
>>I think David was getting at changing colours as much as every raster
>>line, or in the case of the Atari 8-bits, display lists. Also the larger
>>palette helped.
>Yes but you can do exactly the same on VIC-II/TED. And display lists do
>NOT change colors. You still have to do it with the CPU.
But display lists tremendously simplify this. Set up a display list interrupt
that hits WSYNC, and everything is set up properly without counting cycles.
Sure, you can do it the old CPU intensive way, but ANTIC makes this fairly
straightforward with considerably less overhead.
John Selck
wrote:
> But display lists tremendously simplify this. Set up a display list
> interrupt that hits WSYNC, and everything is set up properly without
> counting cycles.
WSYNC only wastes cycles you could use better.
> Sure, you can do it the old CPU intensive way, but ANTIC makes this
> fairly straightforward with considerably less overhead.
a plain rasterbar loop is also quite simple.
Cameron Kaiser
>>But display lists tremendously simplify this. Set up a display list
>>interrupt that hits WSYNC, and everything is set up properly without
>>counting cycles.
>WSYNC only wastes cycles you could use better.
Like counting them? ;-)
I think we're just going to have to agree to disagree on this one.
Sam Gillett
"Cameron Kaiser" wrote ...
> "John Selck" <selc...@t-online.de> writes:
>
>>>But display lists tremendously simplify this. Set up a display list
>>>interrupt that hits WSYNC, and everything is set up properly without
>>>counting cycles.
>
>>WSYNC only wastes cycles you could use better.
>
> Like counting them? ;-)
>
> I think we're just going to have to agree to disagree on this one.
Rather than being a matter of agreeing or disagreeing, it may be a matter of
two entirely different views of, and approaches to, a similar problem.
John wants to take the classic demo coders approach and start by reinventing
the wheel. Then after each revolution of that wheel, he wants to reinvent it
again.
Cameron want to take the programming wizards approach and reinvent the wheel
only when necessary.
However, I agree with those who feel that the C16 is not capable of emulating
the 2600 without additional hardware.
Disclaimer: I don't know what I am talking about anyway, so please disregard
this post! ;-)
--
Best regards,
Sam Gillett
Why is the third hand on a watch
called the second hand?
John Selck
<sgillet...@diespammergte.net> wrote:
> John wants to take the classic demo coders approach and start by
> reinventing the wheel. Then after each revolution of that wheel,
> he wants to reinvent it again.
>
> Cameron want to take the programming wizards approach and reinvent the
> wheel only when necessary.
Nah, I just don't see how display lists "simplify" things. Actually
they make things more complicated compared to raster irqs, since you
can't have a display list irq at any rasterline but only at the end
of mode lines (i.e. every 8th rasterline in character mode etc).
And WSYNC adds absolutely nothing. It's just a wait loop you can
do aswell with normal opcodes. And while waiting, you could also do
something better, like updating even more registers and not only one.