Rybags

Why only 180 words? With some lazy thinking my concept was to put the game onto an 88K disk - probably allowing about 60K for the word data. First letters can be omitted, then just keep an index of where the first word for each letter appears. 4 letters unpacked allows 15,000 words in 60K. From memory the NYT game has at least a few thousand more than that. With more effort, 4 letters could be packed into 20 bits - 3 bytes per word would allow 20,000 words.

I actually started to work on an Atari version of this game early last year. But somehow I managed to lose much of the work I'd done (mainly the key input routine so it wasn't a great loss) Supposedly most/all of the game is actually contained within the webpage you load from the NYTimes site. I grabbed it and extracted the word list about 18 months ago - I think possibly they might have changed the game since then (I do remember there was an archive page that allowed you to play any day's game but they asked him to take it down) I sorted the English words into alphabetical order - my intent was to do an Atari version and use a software LFSR to pick the words at random and allow you to save position and resume etc. Anyway, if you want I can see about digging up the English word list I have and pass it on.

PMs - depends how accurate you want them to be. You have the initial GRAF loads that can be by DMA early in the scanline or by CPU at any time. Then you have triggering for display, not sure what the thresholds are there, it was a long time ago I played around with repeating players on a line. I might be wrong but I reckon handling the priorities might be the hardest part.

No - for a file I mean having the data as it's raw, native value. Atari bitmap like many old computer uses packed (chunky) pixels. So a byte might have bits set like: 0 0 0 1 1 0 1 1 Example there would be 4 pixels with colours 0, 1, 2, 3. Storing the raw data is the most efficient way aside from compression (ignoring procedural generation techniques)

If it's a significant amount of graphics, like over a few hundred bytes then you're probably better off keeping them in a file. Using PLOT is also pretty slow, adding decoding packed graphics could see it take an hour to load a single screen. An entire screen dumped as a 4 or 8K file would take a while to load using GET/POKE (like over a minute) but still be way quicker than PLOT.

WSync can't inadvertantly trigger the missed NMI condition like a correctly timed IRQ, right?

Motor/LED on/off at regular interval after powerup is a result of the self-test failing.

That can have it's risks - custom OSes might have things completely differently mapped out though you might get away with the 2nd charset area at $CC00. Also it can clash with some Doses or Ramdisks that use that particular area. But in the case of a game or adhoc program that's not Dos dependent it's not really a huge issue.

Yep, in general emulators don't talk to the outside world in a way where timing accuracy below about a frame is important. The important thing is that what you see and hear matches what the real hw does. So audio - you can build a frame or two worth and just buffer it. If there's a little audio lag it shouldn't matter much. Video - similarly, build a screen and display it as a real machine would, post-processing for RGB triad or scanlines or whatever, so long as you see it about 1/50th second later then it's fine. User input - possibly more important than the others - low latency desirable but kb and controller input from the PC should be quick and easy to process and pass through anyway.

Basic A and B have nasty bugs and should practically never be used. For NTSC 400/800 you'd generally use it's Rev B. A has some annoying bugs though they'd probably not be a big issue in emulation, there's not really reason to use it. Supposedly PAL Rev A is equivalent to NTSC Rev B, so use that. PAL/NTSC - every reason to use both. Some games are preferable to play in NTSC as the 60 Hz rate will usually mean they are faster. Many modern day demos and games only work in PAL since it has more available cycles per frame. XL/XE OSes - the Atari produced ones should all work on both systems, they coded them to detect and adjust accordingly. There are small differnces among them, like behaviour when a cartridge is swapped (coldstart or just lock up), and the later XE ones support testing >48K RAM. 1200XL - Rev 10 is the common one, unsure if Rev 11 was ever released. For a "default" config I'd recommed probably a 130XE setup 128K Ram, Rev 2 OS. PAL or NTSC is individual taste. If you wanted to go minimal on what Roms you carried, Basic C, and OSes: 400/800 NTSC-B and PAL-A 1200XL Rev 10 XL Rev 2 and 4.

We need clausb in on this - I think it might have been him that devised the 130XE-link expansion for the 800 before the XE existed.

Not sure about 130XE having the first "official" banking. Maybe in a "from the factory" sense. There were 64K expansions for the 800 that allowed the 4K at $C000 to select one of 4 banks. I think they even had 16K bankable at $4000 in similar fashion to the XE, well before the XE came out. And no doubt, there were probably expansions for the Apple II that had bankable Ram.

The OS does hit the D3 page early in the code/warmstart code - the XL is different in that it bypasses it for address D301 (PORTB) It's questionable why it bothers since it's subsequently hitting the mirror copies multiple times. PBCTL is initialized to 00 before it anyway which means that writes to PORTB are only hitting the DDR at that time - the default is that the outputs should all be 1 which = OS present, Basic out. DDR = 00 sets PORTB to all inputs but the outputs retain their previous state. Are you using a custom/aftermarket Rom as basis for your work? Possibly they have different behaviour there.

It hurt that we got screwed over from about 1984 onwards by missing out on ports of games where mediocre competing systems did get it. What hurt even more was losing out on actual Atari games such as that and Klax. http://www.atarimania.com/list_games_atari-400-800-xl-xe-arcade-marble-madness_genre_30_8_G.html Spindizzy and a few other similar games worth looking at.

Doesn't sound right that it'd work at all with that speed increase. Maybe it's a PAL thing with the measuring software but you'd expect a lower not higher number if that was the case. How about just plain writes to an existing disk? Speed jitter - maybe the adjustment pot is dirty and causing that.

I had a cracked version of The City practically weeks after the game came out. I'm fairly sure the one on Atarimania is fine. Though a problem with the game is that even with multiple images mounted on multiple virtual drives, you'll probably still need to do disk swaps.

Do you still have the :. after then RUN <filename> ? to cope with non-space data after the command? If you can guarantee there's spaces for the remainder of the entered line you could lose the second quote. I notice you still seem to be doing SBC to get the screen code, you could just encode the costant string direct. Doesn't AUTORUN.SYS just use a run address only? If an executable omits the INIT address it should just default to pointing to an RTS, that's the DOS or loader's responsibility.

The problem with a cart present is that the memory map (screen, top of Ram pointer etc) will reflect that even after the cart disables itself. So you'd get a boot situation where it's possible that the game or whatever thinks you only have 40K. In theory you could disable cart, re-open screen etc but it starts to get complicated and you can have unwanted residual data left in parts of Ram.

Reads from non Ram can't be relied on to have fixed values - 400/800 will often return address bus reflection, some systems will show $FF.

Turns out I was replying to his tagline (Steril707) - I'm on the dark theme which sometimes doesn't have great contrast. https://www.youtube.com/watch?v=jWxZGg--IqM

Looks pretty good. VBXE could just about do that though the parallax would need to be Antic generated.

Would be interesting to have a dump of it. I've got a "Star Raider" brown cart (normal label aside from lack of second s)

You could probably get away without clearing stuff in the margin - E: will just ignore anything in that region (try POKE 40000,10 then move up and type in a valid Basic line and it will accept it)

It's right. You can work out the bitrates using the same formula that's in the hardware manual for audio frequencies. Of course you have to factor in latencies for command processing and the peripheral fetching each block. But in the modern day we also have emulated devices that can do large block burst IO. I think there's a limitation for IRQ driven SIO - once you get to a certain speed mainline code does polling to reduce overhead.

Thinkinig about it a little more... you could do a kludge method to save copying the commands to screen memory. Just change SAVMSC to point to your buffer containing the POKE, graphics, run stuff. Suffix that with :. so that any residual is treated as a REM. You might need leading spaces to account for left margin. Also, put it at the end of your program in case any output occurs which could corrupt things. The OS will think the screen is in low memory, but the GRAPHICS command once processed will restore it to the appropriate place.