mrroman

The C64's uppercase charset (in fact, this applies to the entire Commodore 8bit line since the PET set the standard) contains a load of extra ROM graphics characters, whilst the lowercase contains the upper and lower case characters and a reduced set of graphics characters - in both cases the latter 128 characters are inverted but all bets are off when user defined characters are in use because all 256 chars can be defined independently. Good to know. I was mistaken by negative chars.

The C64 has 256 characters. TMR mentioned once, that several games change the characterset by rasters, which is much easier on the small ATARI. OUTRUN came along in 1988. It was actually the time, after ATARI dropped support for the 8bits and before the eastern Europe growth for the A8. But, I think this isn't the problem. It's more the "out of the book" programming plus some fears not to have 50fps(60fps) for a game, that stopped even homebrewers from converting such games. I always thought that C64 has 128 chars as Atari. Why you have to change charset to other to use small letters on C64?

did anyone try to use atari 810(http://retrobits.net/atari810.html)?

heh, second address should be: http://www.gdansk-orunia.eu.org/cas/ [/url]

1. yes, they are. 2. there is a program called cas2wav. you can make some wav's of cas images. http://home.planet.nl/~ernest/atarixle.html or http://home.planet.nl/~ernest/atarixle.html. at second are also many cas images.

Perhaps you did follow my thread ".... ears bleeding". The whole thread is about new soundings, how to create them, what's not possible and where are the problems with the available trackers. The response ist extremely low, because most of them don't sound sid'dish. So while the SID-PLAYER is much more noisy, everybody seems to be happy, because it sounds sid'dish. Actually, SID is the more flexible music chip. To play SID-Music with POKEY, will reduce POKEY to 2 voices. Another technical problem is the missing ability of creating sine-waves, which is making pokey always sounding noisy in deeper notes. On the other hand, SID always sounds a bit "dull" and most SID-tunes are suffering by that. Optimizing POKEY-programming in a way like G2F does with the graphics, will give multiple more possibilities to pokey music... even in "standard VBI" programming. Due to the multiple generators and functionality of the generators together and with the 4 sound channels.... with an optimized programming, one could reach a real PAR between SID and POKEY, even if the styles are different. But, at the end, the only (?) style that is requested, seems to be the SID-style SID only produces saw,square and triangle waves. smooth bases are built by low pass filtering. in example by swiety are also emulated lowpass filters.

of course you can do it with atasm. it is normal assembler but compatible with mac65. but i please you and tell you, there is xasm version for linux. it's called zooey. you can find it at: http://atariarea.histeria.pl/files/utils/z...ooey-1.2.tar.gz.[/url]

not quite. it's upside down only in windows.

this hole, which to be cover, is to recognize which disk are you using. is it dd or hd. if you format disk as dd without covering the hole (on hd floppy ), it will format it in hd manner, not in dd. you must format it with covered hole also on MegaSTE/TT with HD floppy. after that, i formated even damaged hd disk and they fully worked as dd. that's because it's using lower density to write on dd.

you dont need 720kB disks. just stick a hole on the edge (not that for protecting disk) in HD(1.44MB) disk , and format disk on atari. it now will work as normal DD(720kB) disk.

i think it should be possible to write 2600 emulator for ST. 2600 is much less complex than atari 800, and is slower. if people are writing emus in python, it shouldn't be hard to write it on ST.

as i know, code compiled by compiler is divided on two parts. code and data. constances are stored as data. other is allocated in runtime. local variables are stored on stack and other, dynamic are stored on heap. execution of code on stack and heap whould be denied. i think all programs are written that way.

Imho is this executable protection attribute a worse solution. How will it work with the available software to give full protection and compatibility? Will the available software still run when the protection is activated? Installing some emulation software will remove this "security" and it does not help against stack overflows though. exploit is started by changing return address of function. if i good remember, code of exploit is running on stack. so if you set stack segment to not execute code, exploit couldn't be started.

you talking about utopia. in today's level of complex it is impossible to build motherboard without failures. it is also another reason, software and hardware is produced very fast. if someone told you in mid 80ies that he built computer in few months, you would laugh on it. Atari ST was build in 6 months (if i good remember) and was very buggy (that's why TOS was booted from disk). you are saying about service pack that you apply. win xp is system from 2001 (in 3 years atari released two TOSes and many patches, and it was not very complicated system) . you must be aware that people make mistakes.

doesn't it depend on implementation? amd in their new cpu gives special attribute to segment, which forbids execution of code. it will be used in patch for win xp in service pack 2. motorola 68k doesn't give you that possibilities. i agree that today's computers don't depend on hardware. i think amiga and pegasos chose ppc because upgrades for amiga used ppc. i also think that it could be written os that implements tos and gem api so soft could be easy ported to new platform. someone could write emulator which would run soft for m68k. it would also implement old hardware. in music, old hardware is implemented as software emulators, because it's cheaper and more useful.