Jump to content
IGNORED

Atari v Commodore


stevelanc

Recommended Posts

 

 

There are other ways to do it, using say the actual charset pointer swapping (no need for badlines or anything for that either) but the above is the way I'd tackle it as a first go. It's a fairly memory hungry method but I reckon you could squeeze the chars into 12k max.

 

 

Charset pointer setting does not help, either you get a badline every scanline or you get 8 lines of a fixed charset.

How to do the spread and shrink effect that is needed to have the depth then?

 

Have a look at Ballblazer on the C64. The only cause for using the interlaced movement is the "badline" or something else that prevents from doing the needed calculations on the needed place...

 

And, well, Dimension X is even more complex with this, and still only needs 4 registers to actuate per scanline on the A8. Possibly it needs only 2 registers for the whole "depth scrolling"...

 

You can change the bank to make the charset point to a different set of definitions on every scanline with no badlines, this is how "tech tech" works, smooth scroll up to 8 pixels per scanline (the same as the A8 version does, smooth scroll I mean, not the 8 pixels bit, that's a C64 limitation obviously) and then switch banks when needed to the new shifted definitions.

 

Anyway, the 1st method I posted is entirely possible and fast so stop trying to pick holes in any other possible methods, especially when you don't understand them properly.

 

Ballblazer, badlines? what? lol

Edited by PeteD
Link to comment
Share on other sites

Does the C64 have anything like a bank switching ROM cartridge like we see on the Atari 8-bit? That is one thing that is strong on the Atari 8-bit with doing 32k, 64k, and 128k carts with an 8k or 16k window. Some of the more memory intensive games probably be hard to do on the Commodore 64. My Tempest Xtreem and Dark Chambers would be good examples. On way around it is have portions loaded from a disk, but that is much slower.

Link to comment
Share on other sites

Does the C64 have anything like a bank switching ROM cartridge like we see on the Atari 8-bit? That is one thing that is strong on the Atari 8-bit with doing 32k, 64k, and 128k carts with an 8k or 16k window. Some of the more memory intensive games probably be hard to do on the Commodore 64. My Tempest Xtreem and Dark Chambers would be good examples. On way around it is have portions loaded from a disk, but that is much slower.

 

I believe so, I seem to remember reading somewhere about some of them being based on 27256 eproms but I could be thinking of something else entirely ;)

 

 

Pete

Link to comment
Share on other sites

Does the C64 have anything like a bank switching ROM cartridge like we see on the Atari 8-bit? That is one thing that is strong on the Atari 8-bit with doing 32k, 64k, and 128k carts with an 8k or 16k window. Some of the more memory intensive games probably be hard to do on the Commodore 64. My Tempest Xtreem and Dark Chambers would be good examples. On way around it is have portions loaded from a disk, but that is much slower.

 

There are.. Around 91-92 the big Rom games arrived from Ocean, System3 and the like, though not many since it was so late in the life-cycle, and these were mainly aimed at the 64GS console.. I actually wrote one of them, Hook, but for technical reasons if was never released in cart form.. They were up to 256K I believe (maybe 512K, it's been a long time!), and believe me the A8 will get eaten for content if you compare against those.. Where-as 256k/320k gets you BombJack, the same in these game is quite a different experience.. 'Smooth and classy' would be a word that pops into mind ;)

 

The whole big rom thing was a mess on the 64, not technically, it worked as advertised (I mean it would given the 64s origins as the Commodore Max/Ultimax/VC-10 which were cartridge based machines) but it was too late really, but some of the stuff is amazing.. Mostly it was nothing you couldn't do on disk, but just a much nicer experience..

 

And to be honest I don't think 64 games benefit from having bank-switched instant access to acres of memory.. It's difficult to make use of it, whereas on the A8 you need it just to make some techinques actually viable in the first place, things the 64 does out of the box in 64K of RAM anyway.. I can't (off the top of my head at least) think of anyway they'd actually improve 64 games apart from near instant loading instead of loading via disk.. I know there's lots of things you can do with it, but I don't see anything that will fundamentally enable something the 64 couldn't do before.. Yet in the A8 case it's enabling stuff due to the unwinding of the whole idea of programming being an exercise in compression :)

 

I can't be arsed to seach them but but here's a list of what was planned anyway.. http://gtw64.retro-net.de/articles/carts.php

To tired to go on a google mission to find what did come out, but from memory Navy Seals was a cracker of a game on cartridge which you should check out ;)

 

But nowdays, as far as I'm aware, nothing happens on carts anymore, I mean game-wise obviously there's gazillions of magic carts out there or various things, but games aren't released in that format..

 

And Dark Chambers is on the A8 ? I didn't know it even existed.. I only have the 7800 version and there's nothing in there I couldn't see a stock 64 doing with nothing but RAM in a single load.. Can't find a version to download, but I'll assume the 7800 is the technically more impressive and (probably stupidly) stand by what I wrote above ;)

 

And totally unrelated except the the Max/Ultimax/VC-10 references above, I think these machines gave commodore the world record for least free memory in a BASIC ;)

As you can see, a Commodore Max with the Mini Basic 1 cartridge plugged in gives you an astonishing 510bytes of free memory :)

maxbasicscreen.jpg

Edited by andym00
Link to comment
Share on other sites

Some things cannot be made up for in software-- like palette, CPU speed, timing accuracy, I/O speed, etc. LMS they can probably get away with in software at cost of more CPU time. I would rather have LMS and line-based scrollability than 1/2 color clock scroll (if I can't have both). That constitutes more hardware scrolling support.

 

 

LMS plus palette changing... the whole depth scrolling is created by 4 (start address plus 2 colour registers) bytes to control per scanline where the palette change happens. Without it, only LMS has to be adjusted... 2 bytes

Someone should add a digi tune playing in the background ;)

 

Looks like 1/3 screen of 3D 60Hz motion and 1/3 screen of horizontal 2D scrolling (if you hold down joystick to diagonals) until you get to the tunnel then it's 2/3 screen 3D.

Link to comment
Share on other sites

Thanks. It looks like a 48K targetted game and pretty good graphics w/o using GTIA modes.
I would also recommend checking out the other titles by Synapse if anyone has missed them http://www.atarimania.com/lst_soft.php?MENU=8&SOFT_ID=&Page=1&TYPE_CODE=G&EDITEUR_ID=1459&VISU=TABLE Rainbow Walker, Alley Cat, Dimension X, Encounter etc. Many of the Synapse titles are amongst my favorite A8 games back in the day. Edited by Tezz
Link to comment
Share on other sites

I was wondering about the C64 cartridge memory usage. One reason why Cartridges are preferred over disk usage is better copyright protection. Even the best copy protected disk format can be duplicated and does not make a difference of who's format you use. Cartridges are much harder to crack. Some games are too large to fit in 64k on either a C64 or A8 where you need to have data swapped in at some point. A cartridge also has instant access to whatever is in their memory banks where as anything disk loaded is much slower.

 

If bank switching schemes were not common for the Commodore 64 until late in its lifetime, it would be a weakness on Commodores part. I don't think anybody can fit all of Dark Chambers just into 64k. I also said doing something like Tempest on the C64 would be hard to cram into a C64 because of certain limitations in clock speed, # of sound voices, and memory.

Link to comment
Share on other sites

I 100% believe that Dimension X can be made on C64...

 

 

You could explain how you would manage to use the zooming tiles...

 

ok.... I remember that when I started to look into Dimension X tens of years ago... the checkboard is prerendered... so actually it is a bitmap on a8. Because of you can move left/right it is not based on 320x resolution but maybe 384 or even more. (Trailblazer are only standard flat stripes col1,col2,col1,col2,col1 btw...)

 

so the illusion of movement is done via DLIs or raster interrupts... you have tables which tell the display code when to invert the colors... so you are moving down until you have moved out of the screen the largest tile at the bottom then you simply reset the movement table... so nothing special here...

 

moving left/right is done via hscroll on a rasterline basis and that's little bit more tricky but nothing special here, too as you are dealing with precalculated values on a scanline basis, too. a simple offset/hscroll table for moving one big tile to the left and then you can reset, too. and this is what I would say will be the tricky part on c64 but they can do rasters, too... so the only interesting thing would be how they handle the LMS simulation but this can be done via recalculated bitmaps or fonts...

 

the game logic is not rocking science like in Elite? isn't it? moving 1-2 sprites around... left right and shoot...

 

just my 2 cents on DX.

Link to comment
Share on other sites

Thanks. It looks like a 48K targetted game and pretty good graphics w/o using GTIA modes.
I would also recommend checking out the other titles by Synapse if anyone has missed them http://www.atarimania.com/lst_soft.php?MENU=8&SOFT_ID=&Page=1&TYPE_CODE=G&EDITEUR_ID=1459&VISU=TABLE Rainbow Walker, Alley Cat, Dimension X, Encounter etc. Many of the Synapse titles are amongst my favorite A8 games back in the day.

 

Synapse where quite innovative in terms of Gameplay, techniques etc... same like the 2nd wave of british companies...

Link to comment
Share on other sites

Does the C64 have anything like a bank switching ROM cartridge like we see on the Atari 8-bit? That is one thing that is strong on the Atari 8-bit with doing 32k, 64k, and 128k carts with an 8k or 16k window. Some of the more memory intensive games probably be hard to do on the Commodore 64.

There are many bank switching carts on C64. All the multifunction carts like Action Replay, Final Cartridge 3 etc have 64k or more ROM on them and also a bit RAM. And then there are a number of games doing that too, although most cartridge games on C64 are pretty old and fit into the normal 8k/16k bank.

Link to comment
Share on other sites

Does the C64 have anything like a bank switching ROM cartridge like we see on the Atari 8-bit? That is one thing that is strong on the Atari 8-bit with doing 32k, 64k, and 128k carts with an 8k or 16k window. Some of the more memory intensive games probably be hard to do on the Commodore 64. My Tempest Xtreem and Dark Chambers would be good examples. On way around it is have portions loaded from a disk, but that is much slower.

 

What's the cost per cartridge on the A8 for the 128K cartridges (assuming you do a run of 100)?

 

I would think flash ram based cartridges would be cheaper and hold more.

Link to comment
Share on other sites

Ballblazer, badlines? what? lol

 

 

Hm... You haven't realized the "interlace" in the game yet? The only cause for this is the fact that they haven't got enough CPU time to do what the game needed to get done....

 

Ah... I think I got it. The flicker is the result of changing colours via rasters. Hard bread without WSYNC or else.

Link to comment
Share on other sites

Ah... I think I got it. The flicker is the result of changing colours via rasters. Hard bread without WSYNC or else.

Perhaps harder than on A8 but can be done. They just didn't invest the time to do it.

 

just for the records... of course little larger than on A8 but available on the net...

 

http://www.canberra.edu.au/~scott/C=Hacking/C-Hacking10/C-Hacking10-raster.html

Link to comment
Share on other sites

Ah... I think I got it. The flicker is the result of changing colours via rasters. Hard bread without WSYNC or else.

Perhaps harder than on A8 but can be done. They just didn't invest the time to do it.

 

They did for sure.

 

Cosmic Causeway.... 128 pixel of 160 possible

 

Rebel Racers 288 of 320 pixel.... but only one sprite per screen used.

 

It's clear what they had done. The invisible range is used for "speedup" because you have a limited value of CPU cycles per scanline.

 

Cosmic Causeway uses less pixel which allows more Sprites.... the movement is fast but coarse btw.

 

Rebel Racers allow more screen width but uses only one Sprite.

 

It's simply the limit of what can get done with VIC II...

 

Well, following the C64 logic, you will also see some Call of duty next time, even if the screen size is about 10x10 pixel.... but C64 will have a full working CoD then. No doubt, all C64 guys will agree, it is.

Link to comment
Share on other sites

just for the records... of course little larger than on A8 but available on the net...

 

http://www.canberra.edu.au/~scott/C=Hacking/C-Hacking10/C-Hacking10-raster.html

 

Is it even possible to generate absolutely cycle stable IRQs on the A8 ?

I mean the 64 has several ways, either using the sprite dma to stabilise automagically, or pointing the IRQ vector into the CIA timer register itself, or simply reading the timer register manually and skipping some cycles.. Is there anything you can read on the A8 to tell give you a cycle accurate value to9 allow the code to fixing up to to chosen cycle boundary ?

Edited by andym00
Link to comment
Share on other sites

Is it even possible to generate absolutely cycle stable IRQs on the A8 ? Without using double-irq techniques ?

STA WSYNC

 

That's the answer I was expecting from Emkay..

I meant at any chosen cycle.. With a timer source, that isn't related to the scanline position, I meant is there a way to read and fixup cycles based upon some modulo count of elapsed cycles ? Any source available to allow some correction for interrupt jitter.. That doesn't involve WSYNC and burning clock cycles like they're going out of fashion..

Edited by andym00
Link to comment
Share on other sites

They did for sure.

 

Cosmic Causeway.... 128 pixel of 160 possible

 

Rebel Racers 288 of 320 pixel.... but only one sprite per screen used.

 

It's clear what they had done. The invisible range is used for "speedup" because you have a limited value of CPU cycles per scanline.

 

Cosmic Causeway uses less pixel which allows more Sprites.... the movement is fast but coarse btw.

 

Rebel Racers allow more screen width but uses only one Sprite.

 

It's simply the limit of what can get done with VIC II...

 

I love how when there's more colours you side-step to "oh, less resoultion", but unfortunately you're wrong there as wel..

 

Look again:

16773.png

Link to comment
Share on other sites

That's the answer I was expecting from Emkay..

I meant at any chosen cycle.. With a timer source, that isn't related to the scanline position, I meant is there a way to read and fixup cycles based upon some modulo count of elapsed cycles ? Any source available to allow some correction for interrupt jitter.. That doesn't involve WSYNC and burning clock cycles like they're going out of fashion..

You can also use POKEY timers and waste a sound channel or two.

Link to comment
Share on other sites

You can also use POKEY timers and waste a sound channel or two.

 

But you set the values through AUDFx and that register when read is POTx and there's no way that I can see to read the current value out from the timer.. So whilst you can by all means use a timer to generate an irq at a fixed rate, there's no way I can see to counter the interrupt jitter that occurs since there's nothing you can read to instantly give some base clock count to correct against..

Edited by andym00
Link to comment
Share on other sites

You could in theory use a spare PADDLEx register, and if the POTGO sequence was started during VBlank at an exact known time, use that to help with syncing.

 

The thing is... you have WSync, which in 98% of cases gives the HALT until near enough the exact spot you need.

 

In the other 2%, e.g. if you had a narrow-screen situation like NRV is using with "Project M", the 6 cycles or so of jitter doesn't really matter since you can just have the Timer occur such that your screen changes would coincide to an offscreen area.

 

 

You can also use POTGO in Fast mode, which in effect turns the PADDLEx registers into cycle counters, although it's only good for 2 scanlines.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...