Atari v Commodore

[+remowilliams]

44 pages. Wow.

 

I've got 3 or 4 1541s (all of which no longer load everything reliably), two 1541-IIs (which work fine), and two 1571s (which work as well). And an Enhancer 2000, which while it is small and works - also sucks.

 

On the other side I've also got a few Indus drives, a Happy 1050, and an XF551 all of which work dandy.

 

This by the way is the best C= drive available.

 

[HiroProX]

Having programmed both the C64 and the 800XL, I think it's telling that my 8-bits of preference are the 130XE and C128.

[Rybags]

It's kinda surprising nobody's bothered doing an APE-like system for the C-64.

 

Existing custom loaders won't work, sure, but who cares?

 

Nothing wrong with a bit of hacking to get existing titles to work. Just look at some of Fandal's work getting disk-based games onto cart, multi-banked games to work on the 130XE etc.

 

The fact you still have to use real disk drives (OK the 1541 Ultimate is there but not exactly the $5 DIY that APE can be) is one of the reasons my C-64 sits in the cupboard but my 130XE is part of my desk setup.

[frogstar_robot]

This by the way is the best C= drive available.

 

Indeed. We can fanboi rant about the drives back in the day but they aren't truly necessary for current enthusiasts. Devices that employ flash and devices that let you turn an old laptop into the equivalent of a stack of drives 10 stories tall make what we used way back when pretty sick.

 

I once built a X1541 cable and imaged a buddy's childhood C-64 collection of BBS downloads and things he'd written for it. Damn ass lot of work for me and that stack of 20 floppies or so wouldn't even put a dent in a 15 dollar keyfob drive. At least recovering his Amiga hard drive was easy when his machine died as some kind enthusiast added Amiga partition tables to Linux.

 

Well that may get the purists to chime in and I'll concede a point to them. Quite a bit of artwork and cleverness sometimes went into making loading sequences bearable. I just about fell out of my chair the first time I saw the mothership launching fighters to Fractulus and I've seen many well crafted splash screens. That and good disk based games like to let you know they're worth the wait. Things like that will often just fly by with the devices we can use now. Interfacing modern kit to these old eight bits is a lot like putting a supercharged Hemi into a Yugo.

[+remowilliams]

It's kinda surprising nobody's bothered doing an APE-like system for the C-64.

Well there's 64HDD but (no offense to the author) it's hardly APE... All comes down to the trouble of true drive emulation in the Commodore area.

 

And the last thing I want in the C64 area is more 'hacked up' games for purposes of making them load on non compatible drive systems/emulators. If I wanted something that couldn't handle fast loader/custom code I'd plug in the Enhancer 2000.

 

Damn ass lot of work for me and that stack of 20 floppies or so wouldn't even put a dent in a 15 dollar keyfob drive. At least recovering his Amiga hard drive was easy when his machine died

Speaking of which, my latest piece of Amiga coolness.

 

Edited December 5, 2008 by remowilliams

[Allas]

Honestly, I use a 1541 since 1985 and stink, I repaired a lot of time along those years. Many time hangs when loading a software, so I had to turn off and on again. Fortunately I bought a 1571 at the later 80's, it's much stronger and most of the problems were resolved. My 1050 drive still work very fine despite I used giant many times more than my commodore drives (since 1984).

 

And i remember very well this situation:

 

[frogstar_robot]

It's kinda surprising nobody's bothered doing an APE-like system for the C-64.

 

That isn't quite so. A little googling found these:

 

http://sourceforge.net/projects/vc1541/ This was last developed on in 2003 but maybe there is enough there there to finish it up.

 

I also found this:

 

http://www.kotinet.com/1541/

 

It is DOS based but the author claims a high degree of emulation accuracy. Being DOS based wouldn't be a killer in Linux as we heathen Linux users have the excellent DOSEMU but who knows? XP might manage it unadorned and DOSBOX has a fair chance at running it. It is also open source and could be ported. The author claims that "multitasking operating systems are out of the question" due to exacting timing requirements but maybe not.

Edited December 5, 2008 by frogstar_robot

[+remowilliams]

I also found this:

 

http://www.kotinet.com/1541/

Both sadly abandoned, though I used 1541emu somewhat until fairly recently. Ville eventually gave up on 1541emu due to the problems with the incredibly precise timing needed. It just couldn't be made to work correctly all the time on different hardware. Even in a real mode DOS with dedicated Lava ports it still was just not enough. Running in an environment like DOSbox is pretty much out of the question.

Edited December 5, 2008 by remowilliams

[atariksi]

sure...but claim was using timer IRQs instead of WSYNC. And to get cycle exact sync without WSYNC...

 

This thoughts are still wrong as any other try of doing it like C64...

 

Why do this thoughts always come to the mind of an A8 coder, heaven?

Why not simply assure that this feature is a fine solutiion on the A8, making many things easy?

 

It's like the first picture you see on in Graph2 font.... A C64 conversion... sometimes I'm getting speechless.... really...

 

simply because I am using Wsync for ages... but Atariski claimed using Pokey IRQs and then you get the sync issue... that's why I was asking... simply "neugier"... of course I am lazy and use Wsync...

 

You can sync without Wsync and save cycles as I have done many times in my software. If you just need scanline accuracy you can just use the 15.6999Khz timer. If you want to split scanlines horizontally, you can use the 1.79Mhz timer. It works; I'll patch the earlier listing for 15.6999Khz timer and repost it... It's not that bad keeping background code in sync as you can always align to scanline or even if you don't keep track of cycles but you know you're close to end of time you can use the WSync in background and sync back on.

[atariksi]

I did not understand your diagram, but you have the multicolor sprites at position 0, 16, 32, 48, ... in PMBase 0. You have the same sprites at position 1, 17, 33, 49... in PMBase 1, and so on until PMBase 15. So it's sort of a warped memory look-up table. The lower nibble of Y position is goes into PMBase (+Starting addr in memory of all PMBases). The higher nibble of Y determines the scanline where to cause interrupt.

 

But this system doesn't work for more than one object.

 

Also there must be quite a large over head in setting up the interupts to handle this - I guess you are using timers, as DLI's may only be occuring on character boundaries? How many cycles are taken up by the overhead of your two interupt routines per frame?

 

You could avoid interrupts and do the look-up on one multicolor sprite and do the memory move on the other one, but that would be way too slow compare to an interrupt structure where you can enable/disable player DMAs.

[atariksi]

...

>That's just arguing semantics again; you're calling two sprites working in tandem a single multicolour sprite,...

...

 

I distinguish between two monochrome sprites and one multicolor sprites via bit 5 of 53275.

 

>i stated my worst case (since the code is always running at that level) and your worst case is when the block copy is required alongside the interrupt ...

 

 

I'm not currently doing any block copies. Worst case you also need to subtract 800+ DMA cycles saved by interrupt structure.

[atariksi]

I doubt the IRQs sync to scanlines in 16 KHz mode, ie they should trigger in a spot corresponding to when you set them.

Ofcourse they can. One scanline is exactly 114 cycles on A8, and you just have to set the timers to 114 cycles too since they run from the same clock.

 

On C64 it's similar: One scanline is 63 cycles, just set timer to 63 so you get 1 IRQ per scanline too (many demos use one timer irq every 8 scanlines to create those big pixel modes).

 

What I mean is - the Timer will be synched to whatever part of the scanline you initiate it at.

 

Despite having the countdown mode that's exactly one scanline in duration, Pokey doesn't have any idea of the H/V position of the screen draw.

 

Unless it's clock is NOT starting when you write to STIMER but just resetting the counter and using the currently running clock at whatever phase it's in. The 15.6999Khz clock is derived from the 1.78979Mhz clock by dividing by 114. If I use a count value of 0 (which is 1 scan line), I can get an interrupt at every scan line and produce the 128 color rainbow effect normally done with DLIs, WSYNCs and setting bit 7 of ANTIC DLs. Saves a lot off setting up time and I can use a VBI's POTGO to read the exact scanline number via 53760..53767. POKEY gives much more accurate INTR and scanline counts than ANTIC.

[Shawn Jefferson]

I just read about four or five pages of this thread and drank an entire kilkenny... good stuff!

 

I had friends who had C64s (and one who had an Atari, Apple II, C64 and IBM PC system in 1983/84 so I was able to compare them all) and I remember waiting like what seemed hours to play GI Joe or Racing Destruction Set (that Atari port is so disappointing!), even with a fastload cartridge! None of my friends had two disk drives, so I never got to challenge them to a "stack off" with disk drives.

 

I have to give Commodore the nod for the sprites, and I think it was a mistake on Atari's part not to come out with a GTIA/ANTIC with better sprite handling capability.. The SID is also very nice, but not a really big deal since it was more the games themselves that mattered and not the music (at least to my friends who all got together to play video games.) Even though, I admit it has more power to do the main thing that we did with our computers back then, play games, due to the sprite system, it couldn't turn me to the dark side. There was just too much I dislike(d) about the C64, the first being the case design... ugh.

 

Reading the thread, and all the arguing about disk drives, I was thinking, "Disk Drives? Who uses a disk drive anymore?" Oh. It's too bad you don't have something as good as SIO2PC and APE... it really does make a huge difference. All my Atari disk drives are boxed up and put away and there's been no real reason to hook one up for years. And I've never blown my disk drive up, and I've done everything you can think of (I once blew some chips in my computer because I tried to hook up the telephone line to the joystick ports on my computer so I could have the computer recognize when someone phoned-stupid!) Same disk drive from 1984 still works, although it was upgraded with a Happy 1050 upgrade, which like the Fastload on the C64, everyone serious about their computer had. Also memory upgrades were pretty much par for the course for your serious computer user on the Atari side. Who didn't run SpartaDOS with their happy disk drives and RAM disks? The MIO was a very cool thing to have (I didn't have one of those though!).

 

So the Atari computer doesn't have 16 sprites, and it's difficult to get colors per line... that's one of the reasons I enjoy it still today. It's limited. There's challenges to overcome to create something unthinkable (but still technically doable) back then. I suspect the C64 people have much the same reasons for still using their old machines... although I sometimes wonder why they hang out at AtariAge.

 

I'm waiting for Oswald to release his new Atari game. C'mon, TMR did one.

[Oswald]

It's kinda surprising nobody's bothered doing an APE-like system for the C-64.

 

Existing custom loaders won't work, sure, but who cares?

 

- there are a few ape like systems out

- 90% of stuff on the c64 has custom loaders. that stuff wont work. I do care.

[atariksi]

indeed, it does have more important things than 128/256 colors.

I doubt that.

Also, A8 has even more important things than that.

 

I can't really agree here. The A8 has a large palette, but limited bit depth. The 64 has greater bit depth bit limited colors.

 

The result is A8 games generally have less coloring, and 64 games have certain sameness from the lack of color choices.

 

C64 programmers see a program and go, "there's color 7, color 2, etc..." Most 8-bit systems don't offer a palette as good as the 64's, though.

 

C64's bit depth of 4 is at 40*25 (color RAM resolution). Atari has same bit depth of 4 at 80*200. Both systems can stretch it via "tricks" which I consider compressed bit-depth.

[Oswald]

Reading the thread, and all the arguing about disk drives, I was thinking, "Disk Drives? Who uses a disk drive anymore?" Oh. It's too bad you don't have something as good as SIO2PC and APE...

 

on the other hand we can upload code into the drive and have it act as a co-cpu if we like thats why sio2pc stuff doesnt works, this kinda stuff needs ms exact emulation, and not even a dos machine can handle it without multitasking.

 

I'm waiting for Oswald to release his new Atari game. C'mon, TMR did one.

 

dont

[atariksi]

Sorry my PC does not have any sprites nor can Amiga sprites do 24 pixel width.

You do realize that things like sprites are workarounds for systems with limited CPU power. If you've got a 2GHz processor and a little bit of RAM, you can have all the sprites you want.

...

Original point was PC can do *BETTER* without sprites. I can disprove that easily: take my sprites curtains example I gave with 80*200*16 or 160*200 image showing as curtains are opened. Now you have a full screen (overscanned) curtains which can be moved with simple HPOS settings. The time required for moving the entire screen >160*200 (32000 pixels) is only a few microseconds as far as CPU load is concerned. Now even the fastest video card on the market today can't deal with updating a 320*200 graphics area in a few microseconds. It would use up more time. Even if it took 30 microseconds to move the curtain, it would require a graphics card that can write more than 1 gigapixels/second to do it in 30 microseconds.

 

>99% of programs don't need more than VBLANK and occasional HBLANK timing. I don't know if this is really a big issue.

 

It depends on the program, but it can make a difference if the timing error builds up over time.

 

>The old PC gameport was an absolutely horrible design. Most games used the keyboard. I don't think it's really an issue today, though.

 

They still have gameports in PCs today. Even my 2.8Ghz PC has a gameport that takes 1 ms to read the joystick. Even if you use a USB joystick, you still need more time to read the I/O than doing one LDA.

 

>>You can take over amiga with simple Move.w $7FFF,$DFF09E, Move.w $7FFF,$DFF09a.

Similar on Atari/C64. But on PC, you can't tell physical addresses from linear or virtual; you can't do I/O w/o OS intervention, etc. H/W is nonstandard so even if you do IN AL,61h to read PC keyboard, it won't run on system w/USB keyboard. VGA card is nonstandard nowadays as well so you can't tell where it's physically mapped unlike older cards where it's always at $A000:0000. You can't call API calls in real-time programming unless you know worst case timing of the API call.

 

>The PC is a totally different animal, but it doesn't really matter. It's so fast that your code executes very quickly and you simply meter the speed at certain points (fps control and whatnot). You'll never have that "real" control over the system, but PC games seem to do just fine without it.

 

You can program for the worst case and assume certain things in the PCs case. But in real-time programming scenarios when something critical needs to be done, you do need to know exactly how many cycles it takes and not an average. So what if a video skips a frame once in a while or if the word processor/browser takes a few thousand extra cycles initially than later, but what happens if you want to control an external device or update a display for some medical system that can't afford to go out of sync. It gets worse w/newere OSes with all these background tasks running that people have no control over (especially if the software is spyware and hogging up your resources).

[Shawn Jefferson]

Reading the thread, and all the arguing about disk drives, I was thinking, "Disk Drives? Who uses a disk drive anymore?" Oh. It's too bad you don't have something as good as SIO2PC and APE...

 

on the other hand we can upload code into the drive and have it act as a co-cpu if we like thats why sio2pc stuff doesnt works, this kinda stuff needs ms exact emulation, and not even a dos machine can handle it without multitasking.

 

Cool. We can do something similiar with upgraded drives and some third party drives. I've never seen much of a use for it. Is there a use for it on the C64, besides replacing the crappy stock drive code to do a fastload ? I'd certainly trade the ability to load code to the drive for the ability to create a stable SIO2PC type device. But I guess that part of the charm for C64 owners, just like having 4 sprites the entire length of the screen is for us.

 

PS. one of the coolest things I've ever seen on a computer was when a friend booted up a demo that played "daisy" (i think) on his 1541. Crazy! Almost turned me to the dark side.

 

I'm waiting for Oswald to release his new Atari game. C'mon, TMR did one.

dont

 

You can't resist the power of ANTIC. Imagine using those WSYNCs. Of course, you'll be banging your head against the wall with the sprites.

Edited December 5, 2008 by Shawn Jefferson

[+remowilliams]

- there are a few ape like systems out

That statement is still way too much of a stretch. A closer statement would be 'there are a few systems out there that sort of emulate drives in some ways' APE is a very complete, amazingly capable animal. I've been wishing for many years for a C64 APE level application, but now I've got the 1541u and while it is a very different approach, is quite something.

[Oswald]

I don't think the c=64 can do anything that the atari 8bit can't.

 

koronis rift is a bad example as it exists on the c64 too.

 

c64 has these as a games, a8 cant even do them as a still pictures to start with:

 

 

or:

 

 

or dont let me start on new techniques like 8 bit digi which can be filtered through the sid:

 

vicious sid mp3s

[Rybags]

I DL'd those "8 bit digis" when they were first posted.

 

They hardly sound 8-bit, in fact I'd call them crap.

[Oswald]

I agree here. Why, with the C64 and A8 followers as one group there would be no stopping us in those other forums against those systems!

I'll tell you something though, those Apple II guys are mean. You can throw all the specs you want at them and they'll just say, "it's just a game system."

 

Nothing gets their hearts racing like a well executed spreadsheet.

 

and the speccy guys. their colors are NICER!

[Artlover]

Creatures and Creatures 2 are the best 8 bit games ever made, ever!

 

 

or dont let me start on new techniques like 8 bit digi which can be filtered through the sid:

 

vicious sid mp3s

I'm assuming sample #3 (vicious sid module 3 VIC.mp3) is an example of VIC generated SIDless sound? I haven't had a real C64/128 set up since the coders came up with the technique so I've never heard it before. Most EMU's don't emulate that AFAIK.

[Oswald]

I DL'd those "8 bit digis" when they were first posted.

 

They hardly sound 8-bit, in fact I'd call them crap.

 

no need to go to speccy forums, their argumentation level is here straight away

[Oswald]

I'm assuming sample #3 (vicious sid module 3 VIC.mp3) is an example of VIC generated SIDless sound? I haven't had a real C64/128 set up since the coders came up with the technique so I've never heard it before. Most EMU's don't emulate that AFAIK.

 

#3 does change background color between black and white, and achieves the sound through the interference between vic and sid in the system. its a very quiet sound. just a stupid technical stunt like playing music with the drive. nothing can emulate it...