Chilly Willy

So is that really a bug in rmac, or in the sound code? Should the labels have been SET rather than EQUed? I could see the author of both arguing the other is wrong.

Pretty cool. I love seeing all the different things people have come up with. I like that idea of using a SIMM for the memory. That was a great way to get a lot of DRAM for relatively less at the time. Anywho, for the /EXTSEL line on my design, run the CE2 signal to the base of a typical NPN transistor. The 65XE would need the /EXTSEL pin on FREDDIE lifted (it's tied straight to 5V in the schematic), and soldered to the /EXTSEL from the expansion, along with a 3K ohm pull-up resistor. 800XL and 130XE systems already have the line pulled high with a 3K ohm resistor, so you would just solder line to it directly on those systems. Need to check the schematics for a 600XL, but I'd guess it's like the 65XE - just pulled straight to 5V. Just checked... the 600XL schematics I found shows /EXTSEL connected to the expansion port and pulled high like it should... the 600XL has PBI? I did not know that...

Looking at schematics for the XL, 65XE, and 130XE, it seems the way to deal with internal RAM is to use an open collector driver to assert /EXTSEL on all models when the expansion memory is selected... that would be driven off the CE2 signal in my schematic.

Yeah, it's kinda the reverse of my idea - latching the other usage and then PORTB is just a bank, while my idea is latch the bank, then PORTB stays the normal function. Seems more compatible to me.

Oh, I read that as a hex constant, not 0-whatever-11-whatever-0. ? It would hold the latch clear, but otherwise act normally. So the self-test would find four banks of ram like the 130XE. Without using PB6 to latch the bits, it should be completely 130XE software compatible. EDIT: I do see an issue on an XL - when the CPU or ANTIC accesses bank ram, it should disable onboard ram. The XE mapper does this, but the XL wouldn't. So the design above isn't XL compatible yet. I need to check into the easiest way to do that on an XL. I do have a couple 800XLs to go with my two 65XEs...

Nothing. You just switch the OS ROM to ram as usual. Unless you mess with PB6 and 7, it acts just like a normal 130XE would. And I already changed the title to 4MB... damn shift key. ?

I was pouting over the lousy 64KB of ram in my 65XE the other day and decided to look into expansion options. It's one of those without the ECI port, so it would need to be an internal unit. Looking at what was out there, I wasn't very happy. How about I try my own hand at it? Here's my initial thoughts on the matter. The idea is 1) it must use the "standard" CIA PORTB for bank control, 2) it cannot interfere with the normal operation of any of the bits, and 3) it should support CPU/ANTIC bank control. I looked at the memory available online... what do you know, there's a 2Mx8 5V 45ns SRAM from Digikey for about $5. Two of them would fill out a full 8 bit bank select just peachy. But how do you get 8 bank address lines from the port without interfering with the operation of the bits? A latch comes to mind. And that's the main thing - a hex D-Type flip-flop. Clearing PB7 will clear the latch, so asserting the self-test ROM will just clear the latch. No problem there. I use PB6 as the flip-flop clock (latched on rising edge). So if this were in an XEGS, clearing PB6 enables the Missile Command rom, which wouldn't be an issue as long as the code to switch banks isn't in either the bank memory space or in the rom cart space. No problem there, either, especially on systems without Missile Command. I use PB5-0 as the inputs to the d-flip-flops... no problems there as long as the code to switch banks isn't in bank memory space, the cart space, or the OS ram space... so in the first 16KB; oh, and the ints are off unless you keep the int code and data in the first 16KB as well. Still not an issue. But how do I get 8 bank address bits from 6 latched bits. Well, just use PB2 and 3 as normal. The latched bits extend them from 2 bits to 8 bits. Use A21 and it's inverse to select one of the two sram chips, use PB4 and 5 along with A14 and A15 and /HALT to generate the other chip enable, a few gates for output enable and write enable and Bob's your uncle. The prices in the pic are from Digikey in single unit quantities for surface mount parts. A handful of bypass caps to round it out at less than $15 in parts... minus the board. That's gonna be the "fun" part. Been a while since I made a board. I'll update as I get further along. Comments and suggestions are appreciated.

To be fair, deasserting COMMAND is the one thing that almost assuredly won't bite you in the rear for not meeting spec on. You're just telling the device "that's it, there's nothing else", so it really doesn't matter that you keep the device hanging on the edge of its seat waiting for another byte that isn't going to come only to be disappointed when you finally deassert COMMAND. ?

Found the bare listing of the rom code. No comments on it, and no labels... just code and data in a plain text file. PERCOM.LST

You align arrays in gcc (m68k) like this unsigned char __attribute__((aligned(16))) rom_hdr[256]; This has always worked fine for me.

Oh, um, that's a 200 DPI approximation of 35 years of dust and yellowing printer paper, not artifacts. ? I could scan it at an even higher resolution so you can see the dirt and age in better detail if you want...

I don't plan on it. I've had that Percom forever! ?? Not sure what you mean... I double-checked the pngs and they are definitely png, and I don't see any artifacts at all. I scanned raw RGB at 200 dpi, and saved as lossless PNG. Maybe your viewer is doing some bad/fast rescaling to show the image. Make sure you look at them at 1:1 as they are BIG scans (2480x3507 typically). But yes, you can make it into a PDF for Archive.org. I get quite a few old manuals from there. Here's a screenshot of part of one at 1:1. Looks good to me... https://i.imgur.com/dXmAlwQ.png

That's probably a bit too much for most people to handle at home. I like my own Sega Genesis converted controller, personally. Very easy to do (as long as you don't have the surface mount style board in the pad), and gives three separate buttons along with a jump (up) button.

I hear ya. Back in the day, I could not make those jumps toward the end and duck the bats at the same time, so I made my own hack. First off, I made it so it would run from DOS on any Atari with 48K of ram. That was tough because of the copy protection. It comes in two levels: the first checks if the "rom" is actually in ram, and was easy to hack. The second checksums the rom and fails on the balloon ride if the checksum fails... you can't change a SINGLE BYTE. I couldn't find that code, so I didn't bother - I rewrote the game code to run below the cart (I had 48K, after all) and left the cart space the same. While I was at it, I added a pause menu accessed via OPTION. Within the pause menu, you can save and load the game to/from floppy, and format a floppy in case you don't have a spare blank formatted floppy. So that section at the end went like this... jump, die, reload; jump, die, reload; jump, MAKE IT! SAVE!! Jump, die, reload... Anywho, I'll attach the xex in case you're interested. I really need to find the source some time... it's on a floppy... somewhere... Pitfall II - Disk Version.xex

This right here is the biggest issue with old Atari computers. The disks going bad, the drives going bad, or both. Back when I still used my Atari regularly (through the mid 90s), I replaced drives about every three or four years. These days, I have an SIO2SD instead. The drive and floppies will NEVER go bad again! ? Other than that, the main thing I noticed is the POKEY serial on the A400 can wear out after four to five years of heavy use. They didn't buffer the serial lines from the POKEY, so the draw eventually kills the serial and you'll need a new POKEY.

Haven't had the time for typing, so I scanned my rom listing instead. Here's an arc. http://www.mediafire.com/file/856b1fye8ott7cq/PercomRomListingRawScan.7z/file

I tuned my TV so that overscan was all but eliminated. Do a search on "service mode" for your TV. Most TVs made in the last 25 years have a service mode, and in service mode you should be able to reduce the overscan. If you have an older TV, it'll have pots on the yoke for the CRT to accomplish the same thing, but it's much harder to do yourself.

Different processor appeal to different people, and that's okay. Everyone has their favorites. Personally, I love the 6502, Z80, 680x0, PowerPC, SuperH, and MIPS processors. I can't stand the x86 or ARM, which makes me sad since x86 and ARM dominate the market now. An SIO2PC or SIO2SD is very helpful in development, and transferring stuff both to and from the Atari. I love my SIO2SD. It's certainly more useful than my AtariMAX cart (not that the cart isn't useful, just not AS useful).

That would be pretty cool. The B-Key is a bit ugly... by modern standards. At the time, it wasn't that bad.

As you can see from my avatar, I too have a B-Key. Awesome upgrade for any 400 owner. It will be interesting to see how many people still use their A400. Mine is pretty old and well-used, so I mostly keep it in its box and rely on my 65XE for most of my day-today Atari-ing these days.

I never worked for Percom, I just got lucky when I bought my first floppy for my Atari 400. I ordered their single-density drive, but they upgraded me to the (then brand spanking new) double-density with built-in printer port for free. The printer port is why they have the 6821 in that unit - they use one port for the drive control, and the other port for the printer. I wrote an app for my Olivetti SparkJet printer for the Atari to print various Atari picture formats, then later made a printer driver for it for my Amiga. But back to the AT88. When my brother got a Happy for his 1050, I wondered if the Percom could do higher speeds. I wrote to Percom asking about the schematics, and they sent me a nice BIG blueprint for the model I had. I pulled the EPROM from the Percom and plugged it into an Atari cart with a socket so I could dump it like a regular Atari cart. I should look around for that. Then I wrote a 6809 disassembler for the Atari to make a file of the disassembled code. I printed it out on my SparkJet and made notes on every routine. Before I could get around to actually upgrading the Percom for high speed, I got an Amiga 500 and moved into Amiga programming.

Finally got around to scanning my schematics for the AT88-S1PD. It could use a good cleaning, but I pieced it together and edited some things that got lost in the scan. Percom AT88-S1PD schematic I'm currently typing up my disassembly of the rom. It's a printout with hand written notes... in pencil... in cursive. Well, it was almost 35 years ago. And looking at the schematic and going over the rom, I have to correct something I said earlier in the thread - the AT88-S1PD has the hardware for high speed serial, but not the rom support. The default the code uses is high speed off, which clocks the serial chip at 16X 19230 baud. It's actually off from what the Atari uses (19040 baud), but close enough I guess. If high speed is turned on (and there's nothing in the rom code to do so), it would clock the serial chip at 1X the Atari peripheral port clock. If I were to hazard a guess, I was working on adding the '?' command to the rom - there's plenty of room in the rom for more commands. I'll probably have the rom listing ready to post next weekend.

Ah, okay, that makes more sense and doesn't come out in the comments. Thanks.

Look at the comments at the tops of the playAndSyncXX.asm files. In particular, playAndSync2.asm says

According to the tester app comments, the type 2 generator doesn't produce clicks as it uses cpu timing rather than pokey timers. Only the type 1 generators click... at least, that's what the comments claim.