danwinslow

I think it won't read it at all.

I have no idea, Ijor. I am familiar with the issues you bring up. I am not trying to solve a specific problem, just commenting on things in general. Having a decently random seed available for constant re-seeding produces a 'better' sequence of randomness, in comparison to a one-time seed.

Well, actually from that it looks like the Atari 8b has a pretty sophisticated random number generator. The $d208 and 'white noise' refer to some very fast polynomial counters used for sound generation and distortion. They serve as a very good external source of randomness, but the algorithm itself is as we described. But, since there is a good source of relatively random 'seeds' available, the randomness producess is probably pretty good. It's interesting to note that, philosophically, nobody is really sure what 'completely random' means. Numerically it would mean a perfect distribution of numbers over any time period...but you don't know if you are in a very long sequence or not until you get to the end...which you can't really do.

Well, I will sure as hell buy one. Or five.

A computer is unable to generate an actually random number on its own. There must be some sort of external randomness that gets measured and then incorporated. The usual deal is to start with a seed, chosen as randomly as possible, and then apply a repetitive algorithm to generate a series of pseudo-random numbers. The series of numbers is always the same for a given seed value, so if you start with the same seed you will get the same stream of 'random' numbers. This is the usual method. More advanced generators sample some sort of external randomness pool every time they calculate. For instance, one system I know of remembered the number of microseconds since the last keyboard input, and reseeded itself every pass with that. *edit* Foe, unless you were very very lucky, your algorithm is probably not actually very random. To test, you should generate several thousand runs of, say, 1-100. Then sort the numbers by the number of times you get a particular value. So if you got 1000 1's, 900 2's, etc. All of your numbers should occur with about the same frequency. If you get 10,000 22's, and 4 3's, that is not a good algorithm. The cumulative measure that your numbers deviate from a perfect distribution is a measure of how random your algorithm is.

What I want to do IS possible, you just aren't being any help. Colours can be lessened, Images can be less-dithered, resolutions can be made smaller! I was not asking to do what I just displayed, I was asking what I needed to do to create an image that WOULD be displayable (if I had wanted to, which I don't) on the 8bit (without drawing it myself.) 900441[/snapback] Well, excuse me. See this part here ? No, its not possible exactly as you showed there. No, you can't display a picture as big as the entire RAM space. No, you can't get any sort of decent 256 color dithering. Next time you get huffy you might consider re-reading your own material. *especially* when you started off by telling us you are too lazy to go find out yourself.

You can't do what you want to do. There are not enough colors available. There is not enough memory available. There is not enough resolution available. This is an eight bit machine from 25 years ago.

Nay, I say! NAY! What are we saying Nay to? Are we the programmers who say Nay?

Well, I am recasing my Falc, and under the impression that the floppy drive cable was connected in a normal fashion to the MB...I gave it a good tug and the cable popped out of the fitting, which is now broken yet still firmly embedded onto the board. Apparantly it does not remove. So..what do I do now? Any advice?

I used an internal MyIDE to put a 512MB compact flash (on a Flash/IDE adapter) into my 1200xl and it worked like a charm. Its great.

A good rant is like oxygen, it should be free to all. And I'm not so much hardcore as just old.

Here's some others I have worked with : PL/1 JOVIAL ALGOL SNOBOL ( really ) MUMPS ADA GMAP BCPL 200 geek points if you know what any of these acronyms stand for, without googling. 100,000 GP if you know them all.

Yeah, that part is old news. The cool thing was how small he got it. Nice work.

Well, I think so. ERASE filename.ext Unless I am rong.

They all blow too. Actually, I took care of Java already. Visual Basic is a mutated form of Basic produced by dissolving Sinclair ZX81's in exotic chemicals in vats in Microsoft headquarters and is thus cool. COBOL? Thats for boring people who just want to sit around and like, make money.

ERASE, iirc

I'll come right out and say it : LOGO blows. So does Lisp, but at least you can actually write programs in Lisp, if you are masochistic enough. Forth is for engineer nerds who think FORTRAN 77 is too high level, Smalltalk is for liberal flannel wearing publishing geeks, Java is for abstraction wonks who like to make up phrases using odd words like 'facade' to describe perfectly ordinary comp sci stuff from 30 years ago that they have just now 'reinvented', C++ is for overly caffeinated control freaks who will argue for hours about inheritance and then go write it in crappy C syntax anyways when nobody is looking, assembler is for wierd ninja-geeks who sit around in dark rooms mumbling about cycles, straight C is for power tripping egomaniacal maniacs who would rather spend twenty hours rewriting ALL of your code BECAUSE YOU DID IT WRONG rather than spend an hour learning to use something somebody else wrote, Pascal is for teachers who flunked out of English class but still wanted to pretend to be superior. And Basic? Basic? BASIC? Basic is for the rest of you.

LOL Um, yeah. Hehe, thanks Ijor.

Ok, some variances from documentation... For some reason I have to send 2 bytes in response to the speed byte request. Otherwise the atari hangs. For 57.6k baud, response bytes of $08 $08 seem to work, and $10 $10 for 38.4 baud. A few of the 32 OS's don't like it, but most seem to do ok. The 57.6 speed instantly crashed Steve's Warp OS though. I'll have to ask him about that.

Hmm, ok, interesting. I changed my routines to cycle through a table of baud rates : 19.2,38.4, and 57.6. Every time it gets a bad checksum it rotates to the next baud rate in a round-robin fashion. That lets it lock in on whatever baud rate is trying to be established...seems to be working for stock 130xe OS at 38.4. I have Steve's 32-in-1 so I will be checking all of them.

Yes...I have seen a few indications of that too...but I am not sure exactly when to switch to hi speed...is it strictly in the data block transmission? This would mean that all normal commands and acking and so forth would happen at 19.2k, and then put/get sector data block would switch into hi speed and then back down? Here's a trace of what I get after responding for $09 $09 but NOT actually changing baud at all : processing header 31 3f 0 0 70 // this is the hi speed query processing header 31 53 0 0 84 // request status processing header 31 52 1 0 84 // read sector 1,2,3 processing header 31 52 2 0 85 processing header 31 52 3 0 86 processing header 31 52 4d 7 d7 // still reading sectors processing header 31 52 4e 7 d8 // still at 19.2k by the way processing header 31 52 4f 7 d9 processing header 31 52 50 7 da processing header 31 52 51 7 db processing header 31 52 52 7 dc processing header 31 52 53 7 dd processing header 31 52 54 7 de processing header 31 3f 4 7 7b // now this is another $3F request...with sector numbers set? processing header 2f fe 2f fe 2f // looks like the atari swicthed to hi speed here? checksum not ok, 47 != 92 processing header f fe 2f fe 2f checksum not ok, 47 != 60 processing header f fe 2f fe 2f checksum not ok, 47 != 60 processing header 2f fe 2f fe 2f checksum not ok, 47 != 92 processing header 2f fe 2f fe f checksum not ok, 15 != 92 processing header 2f fe f fe f

Thanks, Ijor. On point 1 : Ok, I can ignore garbage. On point 2 : I can adapt dynamically, but the question is, when? What conditions might make me need to drop back to the standard speed? Also, why can't I use the $0A divisor? It leads to a non-standard serial baud rate you mean? 52k baud, if I recall. Actually, I can set my own baud rate divisor on the emulation side so maybe I can adapt to that.

Can anyone provide me some information or links to information about responding to a speed byte request? I am working with a device to emulate a disk drive, and I would like to switch into high speed io. The computer opens up the boot conversation with a $3F command, which is a request for pokey speed divisor. If I respond with $28 $28, it stays in 19.k baud mode. If I respond with $09 $09, for instance, that should switch it over to 57kbaud mode. I can swithc my serial line on the disk emulator over to that baud, but all I get is garbage. Here's whats happening : computer sends: 31 3f 0 0 70 ( thats a request for a pokey speed divisor pair ) I respond :ack,complete,$09,$09 I switch line over to 57kbaud. computer sends garbage : fe 0 0 10 f8 Do I have to wait to switch baud rate? Do I have to send a high speed SIO driver? Any info appreciated. Thanks.

Its pretty much the same...but assembler doesn't have sophisticated control structures such as if/then/else, while, case, function calls, etc., and so the use of JMP is very much justified and in fact necessary. As far as 'unlearning rules of code', you are forced into that by the very extreme conditions in the 2600 environment. There's no point in trying to complain about code structure if your pretty little program doesn't fit.

It's not that line numbers are 'bad', its just that they aren't necessary. What they are really is an ordering specification and also a label. You don't need the ordering, as thats provided structurally in the text itself, and if you have a general capability to put a label on a line ( for use with goto ) then you don't need mandatory labels on every line. Goto's are not bad, when used correctly. The only really warranted use, in a language that has other basic control structures, is to provide error jumps out of deep conditionals. If the language has exception throw/catch, then there is no reason at all to ever use a goto.