Urchlay

What horrible thing would happen if you opened it up completely, allowed everything? As already mentioned, only registered members can upload stuff... A file's name doesn't really have anything to do with its content anyway. Maybe the board software should examine the content and determine the MIME type, and exclude certain types (or only allow certain types). If a file starts with a $FF $FF header, it's an Atari executable, can't carry a windows virus, even if its name ends in .exe or .com... What do browsers do if I create a nasty virus.exe file, rename it to usefuldoc.pdf or coolgames.zip, upload it, and everyone downloads it? (Trick question: at least part of what a browser will do depends on the web server and what it sends in the HTTP headers)

First attempt to compile, it's failing with common errors you get with "non-64bit-clean" code: moc_mainwindow.cpp: In member function 'virtual int MainWindow::qt_metacall(QMetaObject::Call, int, void**)': moc_mainwindow.cpp:245: error: invalid conversion from 'int' to 'MessageType::UiMessageType' moc_mainwindow.cpp:245: error: initializing argument 2 of 'void MainWindow::uiMessage(QString, MessageType::UiMessageType)' On 32-bit platforms, MessageType::UiMessageType is probably a typedef for int, and on 64-bit it's something else (long, maybe), so this code will compile for 32-bit but not 64-bit. Either that, or my version of g++ is being stricter about type conversions than yours (what version have you got? Mine's 4.3.3) The fix is, change line 245 of moc_mainwindow.cpp to look like this: case 60: uiMessage((*reinterpret_cast< const QString(*)>(_a[1])),(*reinterpret_cast< MessageType::UiMessageType(*)>(_a[2]))); break; After fixing that, I get similar type mismatch errors in moc_serialport.cpp, and after fixing those, more in moc_sioworker.cpp... I'll send you a patch, when/if I get it to compile successfully on x86_64.

I almost agree: the 410 feels like it's built like a tank, compared to the 1010... but the 410's got this nasty issue where the belt goes around the gear at a really sharp angle, so it develops a nasty kink in it, just from sitting too long. If you use it regularly, it'll last longer... I'm no tape engineer, but it couldn't have been alignment: I'd record something on a new chrome tape, then immediately try to record over it, on the same deck, and end up with both signals on the tape. Even if the deck had been out of alignment with the rest of the world, it was in alignment with itself... the guy who told me it was caused by using chrome tapes was an electronics repair guy (had been doing it for many years), so I believed him. I suppose he could have been mistaken, or more likely oversimplifying things when explaining to me (I was a 15-yr-old kid at the time). The same guy told me "don't use chrome tapes on an Atari tape drive", so I never tried it. You did try it, and it worked, so obviously there's more going on than I understand...

That would be a neat trick, on an Atari. Most games assume they own all the RAM in the machine, especially ones that were converted from cartridge like Tennis. There's a good chance that any random game will overwrite your GUI system (either the GUI code itself, or the memory it's using for whatever data structures it needs while running). Without hardware support for protected memory pages, there's not much the GUI code could do about it... However, a thought... If the entire GUI (code and data both) could be made to fit in XE extended RAM banks, plus a modified OS ROM that handles switching the extended banks on and off, then you could run any software that doesn't use XE extended banks (or anyway doesn't use the same ones the GUI is using). The boot process would sort-of resemble the original Atari ST (before TOS was in ROM, the built-in ROM would load TOS from floppy and store it in "write-once RAM" or somesuch). The actual program-loader code would have to be in the OS ROM, and it would switch the GUI's RAM banks out (and main system RAM in), then load the program from disk the way Atari DOS does, and execute it.. Once the app is running, the GUI code would NOT be running at all, so the app could do whatever it wants to any part of RAM (so long as it doesn't switch in the banks the GUI's code and data live in), and the GUI would be able to pick back up where it left off when the app exits... Your "terminate app" key would have to be the Reset button, but it wouldn't have to cause a full reboot. Maybe the ROM code could checksum the extended banks to make sure they haven't been diddled with by application software, and force a hard reboot if they have (so you could still load/run programs that use the XE banks, it would just take a long time and maybe a floppy swap to "exit" from them). I think SpartaDOS X already does some or all of what I'm thinking about here (it doesn't use a modified OS ROM, but it's a cartridge, so it doesn't need to), but I don't know much about SDX. Probably nothing I'm rambling about here counts as a new idea (for one thing, it's a bit like MTOS)..

Hm, CrO2 tapes... I discovered that, if you record on a CrO2 tape, on a stereo that didn't actually support them (had no "Type II" or "High Bias" setting), it'd work... but when you go to record over them, the old music wouldn't get erased, and would still be audible (and loud enough I'd notice it all the time, not just during quiet parts of the new music). Does the 410 and/or 1010 have this same problem, if you save a program on CrO2, then save over it later? ISTR reading somewhere (hardware manual maybe?) that the 410 was biased for regular iron oxide tapes. I guess it doesn't matter, if you buy new cassettes for next to nothing. Just don't ever re-use them (buy another one for another dime instead). Or, use a bulk eraser (probably a good idea anyway, no matter what kind of tape you use).

Go to a used computer store, or the goodwill, you can probably find an old external modem for $5. See if you can get that to work (at least as far as responding to AT commands). If you've got 2 PCs with serial ports, get a null modem cable (probably $12 or so), and some PC-flavored terminal software, see if you can type stuff on one and have it show up on the other. If none of the above can be made to work, there's no point even trying to hook up your SIO2PC yet...

"COM port not found" sounds like it doesn't have anything to do with your soldering. I bet you get the same error with nothing plugged into the serial port, or with anything else plugged in... you're running windows? Check "device manager" or whatever it's called in recent windows versions, see if you even have a COM1: device. Might be you need to enable it in the BIOS setup menu...?

Nothing computer-generated can be "entirely random"... in fact, the definition of "entirely random" seems more of a philosophical question than a practical one, to me. However... are you sure your not-really-random program was for the Atari? Most of the other machines used a simple algorithm for their RND functions: there would be some mathematical function that gets executed every time RND() gets called, the result would be returned as RND's result, and kept around to be used as input next time RND gets called. Initially there would be a "seed" value, and sometimes a command that would set the current seed to the current value of the system timer, or whatever... On the Commodore machines, IIRC, this was done via RND(TI), and on something (TI 99/4A?) there was a "RANDOMIZE TIMER" command. Anyway, if you set the seed to the same thing every time, you'd get the same sequence of "random" numbers. The Atari BASIC RND function is lightyears ahead of the ones found on most machines of the time period, because of the POKEY polycounter that updates every CPU cycle, whether it's being read or not. I suppose it'd be possible to write a program that autoboots (probably from cartridge) and reads the same "random" numbers from POKEY every time, since AFAIK the POKEY's internal state gets reset to a known state by the OS, during bootup. If the software always reads from $D20A at exactly the same time-since-boot (down to the exact CPU cycle), every time it runs, I think that means it'll get the same results (in other words the poly-counters really are deterministic). I'm not 100% sure about this though (never tested it, and not really enough of a hardware expert to look at the schematics and know for sure). If this turns out to be true, it's basically the same problem as the other machines had with their software random number generators. With a BASIC program that doesn't autoboot, though, it takes the user a random amount of time to type 'LOAD "D:GAME.BAS' and 'RUN' (or, if you use an auto-loader, the program can have a "press Start to play" type of pause, the user will wait a random amount of time before pressing it).

Suppose you're doing a card game in BASIC, and you need to pick a card from the deck. There are 52 cards in the deck (numbered 0 to 51), but RND(0) returns a float value between 0 and 1... you use something like "CARD=INT(RND(0)*52)" to get a number from 0 to 51. More generally, to get a random integer where LO <= N and N < HI, you say "N=INT(RND(0)*(HI-LO))+LO". If LO is zero, it reduces down to "N=INT(RND(0)*HI)". RND(0) by itself can return 0, but will never return 1 *, so N will never equal HI (you can add a +1 to the HI-LO part if you need HI to also be a possibility). * But WHY can't RND(0) return 1? Looking at the source code, the comment "POINT TO 65535" is incorrect: RNDDIV is actually 65536 in FP format. So if the 2 bytes from POKEY are both 255 (max possible value), that'd be 65535/65536, which is less than 1... On the other hand, 0 is possible because both POKEY bytes can be zero, and 0/anything is still 0. So... INT(RND(0)*N) : REM random number from 0 to N-1 INT(RND(0)*(N+1)) : REM random number from 0 to N INT(RND(0)*N)+1 : REM random number from 1 to N ROLL=INT(RND(0)*6)+1 : REM roll a 6-sided die, ROLL is 1 to 6 You get the idea, I think... More likely, in a card game, you want to shuffle the whole deck, then deal out the cards in order after the shuffle. One way to do that: 99 REM Untested code! 100 DIM DECK(52) 110 FOR I=0 TO 51:DECK(I)=I:NEXT I 120 FOR I=1 TO 1000 130 FOR J=0 TO 50 140 IF RND(0)>=0.5 THEN TMP=DECK(J):DECK(J)=DECK(J+1):DECK(J+1)=TMP 150 NEXT J 160 NEXT I Line 110 initializes the deck, then we loop through it 1000 times, randomly swapping (or not swapping) each card with the card after it. This is kind of an "anti-bubble sort" algorithm... "IF RND(0)>=0.5" is a "random boolean" with 50% probability. If you wanted to randomly do something 10% of the time, you could use "IF RND(0)>=0.9" or "IF RND(0)<0.1". The latter is probably easier to read and understand: somethihng that happens 10% of the time, has a probability of 0.1. General formula would be "IF RND(0)<PROB" (line 140 would read "IF RND(0)<0.5 ...") These 2 formulas (number between LO and HI, and probability) are all you really need, most of the time. I can't think of anything else I ever used RND(0) for, back in the day... and this post is probably the most BASIC code I've written in the past 10 years I suppose it's possible you might need random numbers with a gaussian distribution, in which case you'd write something using BASIC's trig functions... but they're painfully slow. Maybe you'd borrow a page from the book of assembly programming: create a lookup table (array), then use a regular random integer as an index into the table.

Nah, here's the source, from the Atari BASIC Sourcebook: ;XPRND-RND Function B08B XPRND B08B A2A8 LDX #RNDDIV&255 ; POINT TO 65535 B08D A0B0 LDY #RNDDIV/256 ; X B08F 2098DD JSR FLD1R ;MOVE IT TO FR1 ; B092 20F2AB JSR ARGPOP ; CLEAR DUMMY FLAG ; B095 AC0AD2 LDY RNDLOC ; GET 2 BYTE RANDOM # B098 84D4 STY FR0 ; X B09A AC0AD2 LDY RNDLOC ; X B09D 84D5 STY FR0+1 ; X B09F 20AAD9 JSR CV1FP ; CONVERT TO INTEGER B0A2 204DAD JSR PRDIV ;DO DIVIDE ; B0A5 4CBAAB JMP ARGPUSH ; PUT IT ON STACK ; ; ; B0A8 4206553600 RNDDIV DB $42,$06,$55,$36,0,0 RNDLOC is defined as $D20A at the beginning of the source...

The trouble with using assembly in BASIC is that USR() routines can only return a 16-bit integer value (which BASIC will immediately convert to floating point). Also, ADR() can't take the address of a numeric variable... so I dunno a good way to replace RND() with a USR() routine (there's no way to return a FP number or store it in a variable). If we did have a way to return a FP value, we could do something like: ; WARNING: Untested code! tmp1 = 0 ; or any other unused zero page NORMALIZE = $dc00 FR0 = $D4 float_rand: ; fill FR0 with a random number 0 <= N < 1 pla ; we're called as a USR routine, get rid of argument count ; We're generating a random number in FR0. Set the exponent to -1 ; since our range is 0 <= n < 1 lda #$3f sta FR0 ; Get random packed BCD bytes, store in 5-byte mantissa ldx #5 digitloop: ; get one random packed BCD byte, $00 - $99 jsr rand_bcdigit sta tmp1 jsr rand_bcdigit asl asl asl asl ora tmp1 sta FR0,x dex bne digitloop ; Let the OS fix the result up, in case it had leading 00 bytes ; in the mantissa jmp NORMALIZE ; get one random BCD nybble, 0 to 9, return in A ; does not run in constant time rand_bcdigit: lda RANDOM cmp #$A0 bcs rand_bcdigit ; top nybble not valid BCD, try again lsr lsr lsr lsr rts It might be possible to write a fast USR routine that takes an integer argument and returns an integer between zero and the argument... usage would be like "R=USR(RANDUSR,10)" to get a value from 0 to 9. This should be faster than the standard idiom "R=INT(RND(0)*10)"... we'd at least be able to avoid the expensive floating point division that RND() does. Another thought: if you have code like "IF RND(0)>=0.5 THEN (do something)" (sort of like flipping a coin), it'd be faster to say "IF PEEK(53770)>=128 THEN (do something)", and the probability should still be 50/50.

Try this: atari++ -image.1 jumpmanjr.xex There are a few of us here... You could try Atari800. It's the original codebase that Atari800WinPlus is a fork of, and it's pretty mature (been actively developed for at least 10 years): http://atari800.sourceforge.net/ Also MESS can emulate the Atari 8-bits, but not as accurately as either Atari++ or Atari800. These days, for Linux, you want sdlmess: http://rbelmont.mameworld.info/?page_id=163 If you're going to compile sdlmess... the MESS debugger needs some GNOME libraries (notably GConf). If you don't have GConf (maybe because you run KDE instead of GNOME), you can disable the debugger with a command like: make -f makefile.sdl NO_DEBUGGER=1 NO_X11=1 OPTIMIZE=3 Don't let the NO_X11 option scare you: the resulting binary will work fine with X11.

From looking at the BASIC source... the RND function works like this: Read 2 bytes from POKEY's random register (RANDOM at $D20A, which is basically an LFSR). Treat them as a 16-bit integer (0 to 65535)... Convert the integer to floating point. Divide 1 by the integer. The consequence of this is that RND(0) can only return 65536 possible values, even though there are many more possible values in the range 0 <= n < 1 that are representable in the Atari BCD floating point format. However, the values it returns are supposed to be evenly distributed (how evenly depends on how close to truly random the POKEY's results are). This wasn't really what you were asking for though, was it?

My fried 4051 was caused by someone spilling orange juice into the keyboard, probably with the power on (years before I got that 800XL). Also the OS ROM was bad in that machine when I got it. The keyboard itself, I had to strip down and clean the mylar thoroughly. Now that 800XL is the nicest-looking one I own. Chips do fail from old age, but more often they fail from abuse... in the 800XL, a major cause of failure would be use of the "ingot" power supply. When those die, they can put out too many volts, or even reverse polarity (I had an 800XL that wouldn't work, checked power supply and it read -1.5V, but it didn't actually damage the computer).

Actually, hm... where are the 4051s in an 800? On the keyboard, or on the motherboard? I have a dead 800 keyboard, replaced it, and the replacement works fine... if there's a chance I could rescue the dead one, it'd be worth it to have a spare.

Most likely you have a fried chip. If you look to the left of the keyboard connector on the 800XL motherboard, you should see two identical ICs with "4051" in the part number (on the board I just looked at, they're TC4051s, in sockets labelled U24 and U25). These are multiplexers, and if one of them dies, half the keys on the keyboard will quit working (it's also possible for only part of the chip to die, so only a group of 10 or 12 keys stops working). If you're lucky, these chips will be socketed... An easy way to test for a bad 4051: swap the two ICs. If the keys that were dead suddenly start working (and another bunch that was working suddenly dies), then it's definitely a bad 4051. If you swap the chips, but the same keys are dead, then the culprit is something else (damaged/corroded keyboard connector is a good candidate). If you swap the chips and the entire keyboard quits working, you might want to try removing both chips, then try each one in each socket (when the good chip is in, half the keys will work). Seems like my bad 4051 would also get noticeably warmer than the good one, but not hot enough to burn my finger or anything. If they're soldered to the board, you'll have to desolder (with braid or one of those vacuum-pump irons). Might as well get some sockets and solder those in, after you're done desoldering the chips. The 800XL is pretty easy to desolder the chips from (the traces are sturdier than the ones in the 130XE, you're less likely to damage them even if you're an inexpert desolderer like me).

It's a regular program, you download & install it... I can't really give you any useful advice for using Slirp on Windows, as I don't use Windows, but it implements the standard SLIP protocol, so it should work fine with FujiChat. About the site... I've been going through what you might call financial difficulties lately, haven't had time to work on FujiChat much, nor set up a new site for it. The project isn't dead, but it's definitely on hold for now.

No, APE doesn't support SLIP. FujiChat uses a standard SLIP link, not special Atari-specific software... if you're on Windows, see if you can find a program called "slirp" for the PC side.

I remember the 1030's built-in terminal program... At one time, my only Atari disk drive was in the shop, and all I had was a working xm301 and a broken 1030 (it wouldn't go off-hook). I found out I could boot from the 1030, which would load up the built-in terminal program, then unplug the 1030 and plug in the xm301, and it actually worked (was able to dial out with the xm301). If I'd had to keep using it for long, I would have tried to fix the 1030, but it was only for a week until my drive got back and I could use 1030 Express again...

From what I remember, Telelink I would work with the 850 interface. You could hook the SX212 up to an 850 using its RS232 port (instead of the usual way of connecting directly to the Atari via its SIO port). Pretty sure Telelink II only worked with the 1030 modem, which is its own strange little beast, not compatible with anything else (except the XM301 maybe). One thing you could try: if you have a disk drive (or disk emulator such as APE), you could try booting DOS with one of the Telelink cartridges in. If DOS boots, then you should be able to use any modem, provided you have a driver for it, and a copy of the driver on a DOS disk as AUTORUN.SYS.

A couple of things... That version of fujichat has a broken loader, which I haven't fixed. If you boot the disk, it gives you a menu, but when you actually run fujichat from the menu, it locks up with a black screen. To actually get it to run, don't use the menus. Instead, format another disk (or disk image if you're using APE), write DOS files to it. Copy your RS232 handler to the disk, then append fujichat.xex (same thing you'd do with a regular terminal program). Also copy fujiconf.xex to the same disk. Run fujiconf.xex once, to create a config file (fujichat.cfg). Then you can run your appended rs232+fujichat and it will use your config. However... to use Fujichat with APE, you'll need an 850 (or P:R: connection), and a SLIP server running on the serial port you connect the Atari to. APE doesn't contain a SLIP server (that I know of), so you can't use your SIO2PC cable as the serial port for Fujichat. I apologize for the sorry state of affairs, I haven't had a chance to work on Fujichat (or much of anything Atari-related) in the past year or so, but that should be changing soon.

I apologize, the fujichat web site went away and I haven't had a chance to do anything about it... Meanwhile, here's a copy of the latest version. ATR image: fujichat_atr-0.4.zip The source archive is apparently too large for this forum software to allow as an attachment, sorry about that.

Hm. I had a friend with a 600XL + 1064, years ago, and we never found any software that would run on my 800XL but not his 600XL... granted, this was a long time ago, so maybe the compatibility problems only show up with newer stuff (I assume you mean recent releases, not old stuff from the 1980s). It might be that your friend's 600XL or 1064 has something wrong with it... possibly a dirty/loose connection that's causing it to fail occasionally, so the machine boots up in 16K mode sometimes? (and/or crashes with garbage if it comes disconnected while you're playing a game)

Don't think anything's missing from that, but IIRC it's got quite a few OCR errors (number 1 showing up as letter I, that sort of thing). The new one, when you're reading it in the browser, you're looking at the actual scan, so you don't have to figure out that "Oh, this word IO is supposed to be the number 10" etc etc. On the other hand, the atariarchives.org one is normal HTML (can use standard browser stuff like ctrl-F aka "find within page"), not a limited Flash-driven interface with "you must log in to download this document".

A bit of (hopefully) constructive criticism: For sample code, please please please don't use stuff like "mva" or "pla:tay". Some of us don't use whatever assembler you're using that supports this non-standard syntax (MADS, is it?). I think sample code should be as generic as possible, to make it useful to as many people as possible... Also, I'd say instead of "lda $d300", it makes the code easier to read if you define "PORTA = $d300" at the top, then "lda PORTA" in the code... Actually, if there's going to be a code repository with lots of people contributing to it, it might not be a bad idea to have someone write up some coding style guidelines. Since the sample code is meant mostly for other humans to read and learn from, it'd help if all the code were written in the same style... Just my 2 cents, feel free to ignore, of course. All of this is meant in a friendly way: I'm not trying to be rude or snarky, I just have some experience writing "teaching" code and I'm trying to help...