stepho

For what its worth, "mount" is a term from the 1960's on mainframes and minicomputers. The operator would physically load a tape or disk pack (a pack of swappable hard disk platters) into the drive. They would then "mount" the tape or disk pack by telling the OS that the media is ready for use. Unix and Linux still use the command "mount" to perform this. It got extended slightly when virtual machines and drive emulation became common but it's still essentially the same thing.

Didn't he say that both boards he designed used the SIO socket and required no internal bods? Unless somebody hacked up the board and fitted it internally anyway.

Since it's a USB connection, 2 thoughts come to mind: Connect the driver to a PC (doing whatever is required for Windows to see it) and connect the Atari to the PC via an SIO2PC adapter. If Windows can see the disk then the SIO/PC software can make it emulate an Atari drive. Downside is that you need to drag the PC around with you. Make an ARM based board that watches the SIO and changes them into appropriate USB commands. Downside is needing hardware and software skills to do all that. Probably not worth it. Or find one of the older IDE adapter boards for PBI, get/make a 40-pin cable adapter for the flex connection, and plug the drive directly into that. As for 50-pins, I'd guess it's like the 44-pin cable that includes the standard 40-pins plus 4 power pins - ie, a superset.

If it ain't broke then it hasn't been fixed enough

Sounds like how Jobs wanted no expansion capabilities on Apple boards, so the design team put "diagnostic" connections on. Quite possibly the Atari design team planned for an expansion port but Atari chose to not use it. Pity, the S100 bus and other similar backplanes opened up a lot of potential.

Similar to 2-degree motion simulators like https://dofreality.com/ Hobbyists have been building similar at home for decades. It's surprising how much realism can be got from a pair of car starter motors that can tip the platform left/right and backwards/forwards. Do you have a link to the centrifuge sim? The only links I can find are for high G scenarios for fighter pilots or motion sickness.

My flight experience is a little different. My actually flying is limited to a Stearman 75 on a tourist joy flight where the real pilot gave me a few minutes of "solo" while he kept his own hand on the stick. Then he did some barrel rolls and stuff - lots of fun in a leather helmet and googles. More interesting is that while living in Hong Kong a pilot friend got me on to Cathay's 777 full motion simulator. Inside the cabin, everything is from a real 777. Every switch, every dial, the seats, the carpets, etc. Once the door is closed, you cannot tell the difference from a real 777. The view out the windows had primitive 1990's graphics, but in the air this wasn't a big problem. Spooling up, I felt the rumble of the engines through the seat of my pants. At push off, I can felt little thumps as the wheels went over the ridges in the pavement. I also felt the small G forces as the plane accelerated, braked, turned, etc on the tarmac. At take off, I felt serious G forces pushing me back into the seat and lots of rumbling. When the "wheels" retracted, I felt a small bump as they hit their "snubs" - all faked but feeling utterly real. As we turn left and right, the cabin physically tilted left and right - with all the correct G forces. Turbulence was fun and also fully realistic. Landing gave an almighty thump (I came in too fast) that probably would have caused serious damage on a real aircraft. As a bonus, he taught us how to do barrel roll in a 777. First, fly under the suspension bridge (he did tells us that the tail doesn't fit but the software didn't pick up on that). Then go up at 45 degrees until it nearly stalls. As it stalls, turn the wheel hard left and the pedals hard right. The aircraft slowly flips over onto its back. Eventually you regain control, complete the roll and go back to normal flying. This is probably the only part where the realism failed. It couldn't do a fully upside down cabin. Later, he told us the cabin dials, indicators, etc where all controlled by an IBM AS400 mainframe. Since the real aircraft also drives them electronically (no mechanical linkages), the realism remains accurate. The view of the cabin from outside was good too. We could see the cabin mounted on top of 6 hydraulic rams. He didn't show it working from outside but you've probably seen it on videos as it dances around on top of the rams. I've played with most of the Microsoft Flight Sim series since 5.1 but after the 777 sim I just couldn't really get into them.

Is it possible to have the atari800 binary detect which hardware you are running on and then call one of the other 2 binaries? In that way, everybody (including scripts) just calls the common atarai800 binary.

No sticker on the EPROM window. Possibly UV light has erased the program.

I had a quick look at your code and couldn't find PST . But I did find your definition of SAVMSC . #define SAVMSC *((word *) 0x0058) I guess you wanted to do something like SAVMSC=0xff at some point. The leftmost * in the define makes SAVMSC equivalent to an integer variable (not a pointer), so this works. But it doesn't work for memset(), which expects a pointer. #define SAVMSC *((word *) 0x0058) SAVMSC = 0xff; // saves 0xff to SAVMSC, ie *(0x58) = 0xff memset( SAVMSC, 0, 1); // writes 0 to whatever is at address 0xff, ie reads SAVMSC and uses that as the address to write 0xff to memset( (byte*)SAVMSC, 0, 1); // writes 0 to whatever is at address 0xff Instead try either of the following techniques: #define SAVMSC *((word *) 0x0058) SAVMSC = 0xff; // saves 0xff to SAVMSC, ie *(0x58) = 0xff memset( &SAVMSC, 0, 1); // writes 0 to address 0x58 Or #define SAVMSC ((word *) 0x0058) *SAVMSC = 0xff; // saves 0xff to SAVMSC, ie *(0x58) = 0xff memset( SAVMSC, 0, 1); // writes 0 address 0x58

Beware that an LFSR sequence appears random but it repeats the same sequence over and over. so if one run gives 10-48-2-17-5-34 then the next run might give 3-19-10-48-2-17 Notice the run of 10-48-2-17 that is repeated.

The algorithm by JetSetIlly is known as Brian Kernighan's method, although it didn't originate with him - he just popularised it. There is one remaining method. Go to this webpage and then scroll down to the parallel method. https://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetNaive https://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel Use the best method for 32-bits - you will have to cut it down to 8 bits (do the 0x55, 0x33, 0x0f steps as 8-bit but skip the 0x01 and final >>24 steps). It has a lot of shifts and adds, so not sure if it will be quicker than the methods above. That web page is also a great grab bag of tricks - although they are mostly optimisations for bigger CPU's than ours.

There's no technical reason why the 2nd track could not have been used for music or adverts (although adverts would make me more and more reluctant to load it or any other title from that company). I suspect it is more to do with Ralph Baer having a patent on it. He mentions this in his book "Videogames: In the Beginning".

No problem. Doing quickie graphics like that are a welcome diversion from work when I'm on a thorny problem.

Matt black (as above) but add red pinstrip where the 2 halves join and in the groove around the joystick panel.

Cool. The source code looks like a one-to-one substitution of assembly instructions for wiz instructions. Even such things like 3 shift instructions in a row, which code have been done as a single 3 bit shift (and which will still compile to 3 shift assembly instructions). Wiz compiler is at https://github.com/wiz-lang/wiz I have no experience in using wiz, but it looks like an interesting blend of low level stuff and high level stuff.

Gamepad on arm Gamepad buttons (small) Gamepad buttons (large) Maybe a bit too small but it might give someone else an idea.

Fun! A maze of twisty passages - all the same!

The joystick is great! Single pixel mod to emphasise the split in the rear cushions.

Don't forget that other companies also continued selling old lines next to the new lines. Eg, Apple updated the Apple II line and sold it alongside the Lisa and Mac. Commodore continued selling the Pet and VIC-20 when the C64 was released . Updating an old line is cheap and uses simpler parts, so the price can be cheap. And there is already plenty of software. The new line has to recoup a lot of development cost and uses more complicated parts, so must be expensive. And there is little software for it at first. So companies sell the old lines to bring in money until the new line is established.

20 year old link has gone dead Try https://web.archive.org/web/20010714054616/http://www.classicgaming.com/features/articles/cgexpo2000/2600keynote/index3.shtml

Ok, now I understand what you are trying to do. It's got nothing to do with the ZX81 method of using the top rows of the character generator ROM to display hires graphics. It's just a way of encoding data statements. Instead of doing: data $40,$41,$42 you are doing data "@AB" by relying on: ASCII '@' being $40 ASCII 'A' being $41 ASCII 'B' being $42 etc I can see that this would work, excepting of course that you already pointed out that non-visible ASCII characters can break it. Naturally, I would avoid it as being unnecessarily cryptic unless you really, really needed to squeeze the number of characters down - like in the 10 line contest with limited character line length.

I like the horizontal gaps too - would be huge looming blocks otherwise. Found the game enjoyable for a short while but feel it needs some moving bits. Eg, moving animals/monsters to avoid. Eg, doors that open/close automatically (possibly depending on your recent actions - eg press button in another room to open and then it closes in 15 seconds or door open/closes when you pick up a jewel). Maybe a teleport to jump to a far away section (makes graph paper mapping more challenging). Possibly the destination is unreachable by normal movement - ie, walled in. Momentum of the player is a bit high for me (kept running into walls when entering new rooms with short entrance area) but that's more a statement of my poor hand control skill. Maybe change the momentum slightly based on the level. Game runs very smoothly - no glitches that I saw. Well done!

Perhaps 3D version of https://en.wikipedia.org/wiki/Hack_(video_game) or https://en.wikipedia.org/wiki/Rogue_(video_game)

Hoo-wee! Much more fun! Thanks.