Jump to content

Chilly Willy

Members
  • Content Count

    842
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Chilly Willy

  1. 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.
  2. 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. 😀
  3. 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
  4. You align arrays in gcc (m68k) like this unsigned char __attribute__((aligned(16))) rom_hdr[256]; This has always worked fine for me.
  5. 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...
  6. 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
  7. 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.
  8. 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
  9. 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.
  10. 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
  11. 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.
  12. 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).
  13. That would be pretty cool. The B-Key is a bit ugly... by modern standards. At the time, it wasn't that bad.
  14. 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.
  15. 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.
  16. 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.
  17. Ah, okay, that makes more sense and doesn't come out in the comments. Thanks.
  18. Look at the comments at the tops of the playAndSyncXX.asm files. In particular, playAndSync2.asm says
  19. 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.
  20. That's pretty cool, but not something many people would be able to do on their own. My conversion of a Sega controller just takes a soldering iron, some solder wick, some solder, and a couple replacement resistors. But I did like the toggle switch to switch between connecting to UP vs a third trigger. It would be like if I put a switch between UP vs START. But the Sega controller has four buttons, so I didn't need to choose, I could have both UP AND a third trigger (which I made START).
  21. Hi! Been awhile... after my dad passed away, I wound up moving, and the move gave me an ulcer... life sucks sometimes. Anyhoo, I finally got around to unpacking my 65XE and found I needed a stick. Not content with the old 2600 stick, I decided to make my own. So I looked over the threads to see what other people were doing, then decided to do it better. 😎 I love my Sega Genesis control pads. They're the best of the old systems. And the old 3-button pads (which actually have four buttons) looked to be a great place to start. I figured that I could make B the standard trigger, A the secondary trigger most people do for 8-bit/2600 pads, and then make C the same as up. On old 8-bit systems with their single button, up was jump on a great many games, so making C the same as up means that you have a jump button right next to the trigger button. That leaves a potentiometer line open, so I hooked that to the START button. So my control pad has two triggers, a jump button, and a separate START/PAUSE button. Noice! So let's get this puppy going! First, take the control pad apart. It's easy - there's just several cross head screws on the bottom. No special tool required. The PCB will look like this Ho! Lucky!! It's not surface mount. Older pads are like above, and newer ones are surface mount. The procedure to convert into an Atari compatible pad is exactly the same, it's just a lot more fidgety soldering. So I really lucked out on that one. So, next we remove everything but the cable. Yes, everything. Now you want to swap cable pins 5 and 7. Next, bridge IC pads 3 and 4, 6 and 7, 9 and 10, and finally 11 and 12. Solder a wire between IC pads 1 and 14. Then solder a wire from the pads that used to have the pull-up resistors connected to C and UP. Finally, solder 330 ohm pull-up resistors in place of the original pull-up resistors on A and START. The size of those resistors isn't that critical. I used 330 ohms because that what was suggested in the original A2600 two-button stick document. It could be anything between 200 and 6700 ohms. The smaller the resistance, the more power it takes, but also the quicker it will charge the potentiometer line. If you've done it all correctly, it should look like this Note the 1/8th watt resistors. Is that okay? Hmm, P = V^2/R, so 25/330, or about 76 mW, which is about 1/13th of a watt. So, yeah, it should be fine. If you wanted to use a resistor below 270 ohm, I'd suggest going with a 1/4th watt resistor instead. A quick check with the volt-ohm meter to make sure nothing is shorted and put it back together. See? Not that hard. Well, maybe this might help... it's some notes I made to keep it all straight in my head... And finally, here's a link to an arc of all the images, and a tiny test app that will show your new control pad in all its glory! Source is included. I assemble my A8 stuff using atasm these days, but you could also use M65. http://www.mediafire.com/file/kkwkb99zjwu5fyp/SegaJoyPad.7z/file
  22. First, the only thing in common with the code he gave me was the code that stalled the VDP. Second, I made changes to that code making it work better, and under more conditions, so it wasn't at all cut-n-paste. I also arranged for someone with a better understanding of the VDP to do new code that is better/more reliable than the original. No code at all from the original exists in the current code. There's more of that over at SpritesMind where we worked the whole issue out. It wasn't more than just a minor misunderstanding that we worked out, and everyone was better off for the whole mess. I never said it was "easy", I said it wasn't a big deal. And from your own posts, it's not a big deal. Not easy, but still not a big deal. I was going from your posts on one of your ports concerning the color changes. I have no idea how you did it, but I have a few of my own... untried of course, but still reasonable ideas. For example, have the video in 256 color mode and bump the palette index used when converting the colors to use the index, which is itself bumped each time the palette registers are set by the 68000. That would handle up to 16 changes of the palette per screen. For more than that, depending on the game, I'd probably setup the blitter to alter the color table for each line and have a palette for every line. Obviously, some methods will work better than others depending on the game. For example, Wolf3D for the ST sets the palette for the main screen in the vertical blank, then changes the palette for the status bar at the first line of the status bar. For that, I'd keep two palettes and split the screen into two OP bitmaps, each using the proper palette.
  23. Excuse me, but I was defending YOU. Did you actually read what he wrote? That's him talking about everything YOU have been doing here lately. All those ST games you've ported for Jaguar folk - he's spitting in your face, so don't go spitting in mine when I defend you. Anywho, I went back and checked some old ST code, and it's not DMA, but using the HBL ints to change all the palette registers. A simple mistake given how long it's been since I did anything for the ST. You don't need to be snotty about it... especially as I'm on YOUR side.
  24. No, it isn't. It's not the same at all. Programming is a highly mental task, and many aspects can simply be conferred through suggestions and code snippets and the like. I don't need to make an entire program to tell someone how to do an integer multiply and divide on the 6502, nor make a program to demonstrate using DLIs as opposed to POKEY timers. You just TELL THEM.
  25. You're confusing source ports with the ports like CyranoJ has been doing, which is the type of port being asked for. Virtually NO Genesis games have the source released, and therefore there will be NO source ports. In which case, porting IS more like emulating. And that is the biggest load of crap I've ever heard. It certainly is clear you are not a coder. That sounds more like an attempt at insulting certain coders than anything else. If it wasn't meant as an insult, you really found the worst possible way of wording what you meant to say. Porting is very often one of the most challenging tasks a programmer can do. Even with the source, making a game meant for one platform look it best on a completely different one is a challenge most programmers aren't up for. Programmers who do source ports make good money because they're in high demand.
×
×
  • Create New...