Jump to content

Rybags's Photo

Rybags

Member Since 29 Sep 2005
ONLINE Last Active Today, 7:02 AM

#3171068 RP9 File Format

Posted by Rybags on Thu Feb 5, 2015 11:09 AM

I'd prefer an approach similar to how MAME does it.

 

Keep assets like Roms, Samples, Screenshots, Manuals, Artworks seperate.  Make it up to the user whether or not they want the extras included within their overall emulation library.

As nice as it would be to have an emulator setup where you had the manual, screenshots, box art within easy reach, it has the potential to become massive bloatware where an Atari collection might take 20 Gig instead of 2.

 

A database file would be preferable IMO - for each game have cataloged the common name for launchable ATR, XEX versions.  Allow the user to be able to asssociate other files to a given game (e.g. for self-modified versions).




#3167007 Whats difference between commodore 64, amiga, tandy

Posted by Rybags on Sat Jan 31, 2015 10:36 AM

C64 has only 8 function keys (although represented on 4 actual keys).

Amiga has 10 function keys.

Tandy 1000 has 12 function keys.

 

Aside from those things, they're practically identical.




#3166626 Project Veronica

Posted by Rybags on Fri Jan 30, 2015 8:21 PM

The logical way to do sound would be to pre-process.  e.g. for SID emulation, just calculate the resultant sample values for each upcoming scanline with the '816 and have them ready for the 6502 to read via Timer IRQs in the next frame.  At 15 MHz, such processing should allow relative HiFi vs existing methods at probably 20% or less CPU expenditure of the '816.

That leaves the remaining cycles for the '816 to do rendering, calculating, other stuff.




#3165301 Another very early WIP

Posted by Rybags on Thu Jan 29, 2015 4:15 AM

Nice assortment.

 

For button assignment, you need hyperspace as a non-fuss straight up thing, smart bomb also but slightly less urgent.

 

I'd go with RT's idea except straight up for hyperspace, held down for smart bomb.

Of course, best would be to allow the user to configure to their own needs.




#3164420 BASIC Ten-Liners Contest 2015

Posted by Rybags on Wed Jan 28, 2015 3:53 AM

Probably a good idea to publicise it at Lemon64.com as well - it's probably the biggest C64 forum.

 

I'll try and get in again, hopefully with more entries, and take advantage of TBXL this time.

C64 would be really interesting given the 80 char/line limit and somewhat simpler Basic.  But I suspect we could implement similar tricks to A8 to cram more into each line.




#3159294 Reds1F14 and Kratters31 are no more

Posted by Rybags on Thu Jan 22, 2015 2:04 AM

The shit-bagging that went on over Centron3D was 100% deserved.

 

He carried on as if he was the only person in the world developing for Atari, he treated people here as if they were just dipshit collectors with little technical knowledge.

He made claims about his graphical mode and I and others uncovered the truth and revealed it not to be the marvel some thought it to be.

Bottom line - we called him on his bullshit and he just went psychotic about it.  The Atari scene is better off without him.




#3157867 I wonder why no one posted this already... NEAR

Posted by Rybags on Tue Jan 20, 2015 6:10 AM

Some real nice parallax effects there, Cananbalt is half done for us in that first part, and the grafitti tunnel at the end is pretty amazing.  Like the rotating cubes also.

 

One annoyance though, and something we all need to learn from - since we have modern TVs and emuation that shows more overscan than the old days, a couple of NOPs are a good idea if time allows after WSYNC when doing the colour effects to avoid the next colour appearing on the current scanline.




#3156145 Atari 8 Bit I/O Performance vs C64

Posted by Rybags on Sat Jan 17, 2015 9:43 PM

A disk has to have sector interleave, all that is is the offset of sequential sectors physically.

 

The Atari drives spin at 280-300 rpm, so no stock drive will read more than a sector in a revolution.  The only ones that can are the modified drives that allow entire track buffering, but still in any case the serial interface is a bottleneck.  An entire track will be anything from about 1,300 - 4,600 bytes of data which in a best case (accelerated IO)  scenario will take the same time to transmit as several disk revolutions anyway.




#3156134 Atari 8 Bit I/O Performance vs C64

Posted by Rybags on Sat Jan 17, 2015 9:28 PM

Stock drive speed on Atari is fairly quick compared to stock C64 - 1541 transfer supposedly about 300 bytes/second compared to about 1,900 for Atari though in the real world a stock Atari drive does about 1K per second.

 

Turbo loaders on the 1541 will in practically all cases be faster than Atari drives.  But hardware enhancements to Atari drives typically increase transfer speed by 2, 3, 4x so will be comparable or better to 1541 turboloaders.

 

Advantage of turboloader on 1541 is it works with practically any drive at no cost or modification needed (aside from the ones which convert the drive to parallel IO).

Disadvantage of 1541 is that the user has to manually type in the load command.  Most Atari software will autoboot which gives it a head start.

 

C64 tape speed - at stock it's supposedly 300 bits/second which is half Atari's rate although Atari uses stop/start bits, C64 doesn't (?) although it uses parity bits.

Atari penalised by using short blocks with 128 bytes payload, C64 penalised in that standard tape programs are saved twice, second copy used to correct errors found in the first.

 

C64 tape turbo loaders significantly increase it's speed to the point of being quicker in many cases than their stock 1541 disk drive.

Atari can also do turbo tape but software only solutions only provide small speed increase (probably 1/3rd at best) although hardware mods exist for Atari tape drives to provide significant increase.

 

 

Other systems like BBC, Apple II - their disk drives much quicker than stock Atari or C64, the reason being that the disk controller is inside the computer and the computer will usually directly control the drive rather than relying on a slow serial interface.




#3153348 Quite Commanding....

Posted by Rybags on Wed Jan 14, 2015 5:44 AM

Impressive - CC was one of the best games for the ST, I bought it and played a fair bit in the day.




#3150780 P/M graphics unused memory after PMBASE

Posted by Rybags on Sun Jan 11, 2015 12:37 AM

I thought that too, but probably not.  More like "it is what it is".

 

Logically you'd either have what we have, or the 4 players first in memory followed by the missiles.  That layout would make more sense, but consider some Antic workings:

 

Missiles are DMA'd first, and missile DMA can be active without players but players can't be active without missiles - a design which allows some objects (missiles) with minimal DMA interference.

 

So, logically with the chosen design and the missile DMA occurring first, the memory mapping is like we have - all that's needed is to bump the DMA address by 128 or 256 after each object depending on mode.  Alternately they could have put the missiles at PMBASE and just had the players following with PL3 jumping the 1K boundary in 2-line mode.

 

Possibly looking at the Antic decap and schematics could reveal more.




#3147811 Vertical Blank, how to restore?

Posted by Rybags on Tue Jan 6, 2015 7:10 PM

On the computer it's easy to restore to the system defaults since they're in the system Jump Table.

 

Immediate VBlank, either set VVBI to $E45F or copy the word at $E460 to $222.

Deferred, either set to $E462 or copy the word at $E463 to $224.

 

You could also do it via save/restore which would allow a previously user-defined one to continue working.

There's not really an arrangement for "chaining" - generally at a given time you take a VBlank vector and don't worry about the previous use.  Of course you usually end Immediate VBlank routines by jumping back to the OS code though.

The danger with save/restore can be that if you call your init routine twice, then your routine might become the "old" as well and get restored to on exit.  Way around that can be to do a compare, generally if the high byte of a VBlank vector in >= $C0 then it's pointing into the OS Rom.

 

For 5200, there's no jump table and good practice would be use save/restore method just in case a custom OS is installed (there's supposedly only 2 official OS versions).

5200 is a much more closed environment though, so anything on cart will usually get control and never pass it back to Dos, the OS or a running language like the computer.


  • slx likes this


#3146281 Portable VCS

Posted by Rybags on Sun Jan 4, 2015 7:48 PM

Way nice construction - I assume they're using a real 2600 board and not a Flashback one.

 

But the price, really a touch over twice what I'd reckon it's worth.  And given it's CNC machined you would think they could churn them out by the dozen.

 

Battery life pretty poor too... 600 mAh is somewhat pathetic, most mobile phones these days have 3 times or better.




#3145713 RGB - a game for the ABBUC Software Contest 2014

Posted by Rybags on Sun Jan 4, 2015 1:29 AM

Finished Hard from start to finish in one go at last.

 

RGB hard finished.png

 

I can generally do Levels 0-4 in an "optimal" sense where I'm getting near the highest possible score every time.

5 thru 7 is very different though.  In general you can lose 20+ seconds per level just waiting around for shoot/avoid opportunities.

 

On the lower levels you can usually just rush through with little regard of being shot - so long as you do the level in the proper order you almost always get away with it.




#3140960 Klax for Atari 8bit?

Posted by Rybags on Sun Dec 28, 2014 5:23 AM

As "good" as the 2600 version is considering the hardware capability, the computer deserves a proper conversion.

 

It's one of the tragedies of Atari that later in life it missed out on so many arcade conversions - for 3rd parties to abandon the machine it's fair enough but for Atari themselves to release or licence Klax for so many other platforms yet ignore the 8-bit computer line was a kick in the nuts for faithful customers.

 

I think the technicalities have been discussed elsewhere here, but there's plenty of ways that the game could be faithfully recreated and at least look as good or better than most of the other 8-bit versions.